Tables of Tables vs Unions - Flatbuffers Usage Question

[Brian H]

I have a flatbuffers question I was hoping I could get some help with. 

I am trying to use flatbuffers to form up a command buffer that looks similar to the following:

+------------+------------+------------+------------+------------+

| Cmd 1      |  Cmd 2     |  Cmd 3     |  Cmd 4     |  Cmd 5     |

| Type x     |  Type x    |  Type y    |  Type z    |  Type y    |

+------------+------------+------------+------------+------------+

The flatbuffers schema I currently have is:

// Complete command buffer. It is made up of one or more individual commands
table CommandBuffer {
 cmd_array: [Command];
}


// Individual commands, these are placed in the command buffer. A single command
// can only have one of the listed command type fields populated.
table Command {
 cmd_x: CmdXType;
 cmd_y: CmdYType;
 cmd_z: CmdZType;
}


table CmdXType {
 field_x_1: ubyte;
 field_x_2: short;
 field_x_3: string;
}


table CmdYType {
 field_y_1: ubyte;
 field_y_2: string;
}


table CmdZType {
 field_z_1: ubyte;
 field_z_2: [ubyte];
}

Whilst I currently have this working, I feel that using a union instead of a table of tables might be a neater solution to this problem. Does that sound correct?

If this is correct, I've had a lot of problems getting it working and would greatly appreciate some help from the flatbuffers community on what the serialisation and de-serialisation code should look like? I've tried using the test code provided with flatbuffers to achieve this, but to no avail.

Thanks in advance for any help people can provide. 

Cheers,

Brian

[Ken Suenobu]

Whilst I currently have this working, I feel that using a union instead of a table of tables might be a neater solution to this problem. Does that sound correct?

If this is correct, I've had a lot of problems getting it working and would greatly appreciate some help from the flatbuffers community on what the serialisation and de-serialisation code should look like? I've tried using the test code provided with flatbuffers to achieve this, but to no avail.

Brian:

Make sure that when you do (de)serialization, that you're specifying what the root object is.  Once you do that, you need to make sure to "finish" the buffer.  Only then will you be able to actually serialize the object into its byte format.

So, once you have a "root_type CommandBuffer" in your code, you shouldd be able to generate the root object.  Once you do that, FlatBufferBuilder is told where its position and offsets should be, and you can then serialize the object to the filesystem, database, or memory.

I hope this helps.

And personally, I would probably refrain from doing anything fancy with a Union.  Just make the object, and check for nulls on the other objects.  :)

-- Ken

[Brian H]

Hi Ken,

Thanks for the reply. Good pickup, I did miss out root_type line from my code above, but I can assure you it is in my actual code. Sorry about the confusion.

It sounds like using a union in place of my table Command object above is not the best approach and I should continue as I have done. Does that sound correct?

Thanks,

Brian.

[Ken Suenobu]

Brian,

I'd have to agree.  A union in this case would probably not make sense.  It would make sense to embed all of the objects, but assign them as null values where they don't apply.  The code doesn't necessarily need to be elegant on your end to work.  Just keep it simple.  ;-)

-- Kenji

[Wouter van Oortmerssen]

To use unions, you'd have to do something like this:

union Commands = { CmdXType, CmdYType, CmdZType }

// Complete command buffer. It is made up of one or more individual commands

table CommandBuffer {
 cmd_array: [Command];
}

// Individual commands, these are placed in the command buffer. A single command
// can only have one of the listed command type fields populated.
table Command {

 cmd: Commands;

}

table CmdXType {
 field_x_1: ubyte;
 field_x_2: short;
 field_x_3: string;
}

table CmdYType {
 field_y_1: ubyte;
 field_y_2: string;
}

table CmdZType {
 field_z_1: ubyte;
 field_z_2: [ubyte];
}

Is that what you did? What were your problems in serializing it?