Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Draft catalog flatbuffers schema #82

Merged
merged 7 commits into from
May 19, 2020
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 78 additions & 0 deletions scratch/laurentiu/catalog/catalog.fbs
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
/////////////////////////////////////////////
// Copyright (c) Gaia Platform LLC
// All rights reserved.
/////////////////////////////////////////////

// -*- mode: java -*- // Java mode works for emacs to edit flatbuffers.

// Identifiers are stored outside the payload.
// Foreign keys are represented as int64 because flatbuffers does not yet support GUIDs.
// If data size is not a concern, all integers can be made 64bit.

namespace gaia;

// This tracks high level information about types.
// Scalar types have hard-coded entries.
table types
{
name: string;

// For indicating struct or table in flatbuffers.
//
// Note: this catalog representation does not support union and enum.
// Support for them can be added post-Q2, if needed.
//
// 0 = scalar, 1 = table, 2 = struct, 3 = enum, 4 = union
//
// Builtin basic types would be marked as scalar.
category: ubyte;
}
LaurentiuCristofor marked this conversation as resolved.
Show resolved Hide resolved

// Any complex type is defined as a set of fields,
// with fields possibly being of complex type themselves
// (although this may not be used currently).
table fields
{
name: string;

// The type of the field.
type_id: int64;
LaurentiuCristofor marked this conversation as resolved.
Show resolved Hide resolved

// The type that owns this field.
//
// This enables us to collect fields under a type.
// It also enables us to describe complex, hierarchical types.
owning_type_id: int64;
LaurentiuCristofor marked this conversation as resolved.
Show resolved Hide resolved

// Indicates whether this is an array type and if yes, what kind of size it has.
//
// 0 = variable size, 1 = not array, > 1 = fixed size.
//
// Do we need to support arrays larger than 4B?
repeated_count: uint;

// Monotonically assigned identifier, to maintain the order of fields in flatbuffers schema.
//
// Do we need to support more than 65k fields?
ordering_id: ushort;
LaurentiuCristofor marked this conversation as resolved.
Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Flatbuffers allows you to explicitly assign integer IDs to fields ala protobufs, with the id attribute. Can that work for our field ordinal value?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I didn't think of that. The ordinal was just mean to keep the order. I'm not sure if anyone planned to assign ids for access - we could use these ordinals for that as well.


// For deprecating fields.
deprecated: bool;

// Indicates whether the field accepts null values.
// Will require some flatbuffers modification to support null values.
// Mapping null to missing does not work for structs
// and may not be possible for tables either
// because we will probably avoid missing values to allow updating fields in-place.
nullable: bool;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Any field in a flatbuffers table is nullable by default (absence is denoted by an offset of 0 for that field in the object's vtbl).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, but this was meant to track whether the field should accept null or not. In tables, you can treat null value as missing, but in structs we'd need some other approach.

Copy link
Contributor

@senderista senderista May 18, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, in that case I think we'd need to track a user-defined "missing" sentinel value in our schema representation. Or just say that all fields in a struct are required as flatbuffers does.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, missing may not work for tables either. We've had an early discussion where we've said that we'd need to avoid missing values in production, to allow in-place updates. flatc has an option to allow default values to be written in the serialization. The null discussion may need to wait until after Q2, to be fully addressed.

}

// A table will have its own identifier as well as a specific type.
// Several tables can share the same type.
table tables
LaurentiuCristofor marked this conversation as resolved.
Show resolved Hide resolved
{
name: string;

// Indicates the type of its payload, which gives us all the fields.
type_id: int64;
}