Steve, You addressed both use cases in perfect way! Emanuele is studying your code to help you on integrating everything on current code base and get all the test cases to work.
While the serialization seems at good point, I've a few questions: - did you keep the layer between serialization and ODocument? I'd like to explore also the way where the ODocument doesn't contain the Map of fields but rather work against the byte[] - do you already have written serializers for all the supported types? - how many test cases are broken? - do you already have some numbers about first benchmarks? Lvc@ On 24 May 2014 02:45, Steve <[email protected]> wrote: > Dmitriy, > > Currently the name catalog is per class. SCHEMALESS is a special class so > there is a global name catalog for schemaless documents. > > I've just pushed an update that enables setting the option to embed field > names in the record header for fields that are not schema declared. This > is a per class option although the header format allows this to be done on > a per field basis if we implemented a couple of variations of > ODocument.field(). In theory you could set it globally by setting the > option on the SCHEMALESS class. > > The variation of header format is simply that nameId == 0 is reserved as a > marker to indicate embedded field name. If so then the name is stored > immediately after nameId as varint(string length) + stringBytes. > > commit is here: > > https://github.com/shadders/orientdb/commit/079a87decd051290addbb294930ddce63054a19d > > > On 24/05/14 01:30, Luca Garulli wrote: > > Hi Dmitriy, > Everything is still open and what Steve created is a POC to study the best > serialization mechanism for OrientDB 2.0. I personally like to manage > schema-less fields at the tail of the records. > > Lvc@ > > > On 23 May 2014 17:21, Dmitriy Krasnikov <[email protected]> wrote: > >> I tried to follow the discussion, but it went from storing field names >> and serializations of classes, to binary serialization too quickly. >> What is a final decision on storing fields for strict class definition? >> I am a little afraid on global field catalog, for a cases where millions >> of records created with schema free layout and system looking up and >> creating new fields in catalog for each record. Schema full class >> definition vs Schema free class definition sounds like perfect solution. >> Are you still considering it for 2.0? >> -- >> >> --- >> You received this message because you are subscribed to the Google Groups >> "OrientDB" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > > > -- > > --- > You received this message because you are subscribed to the Google Groups > "OrientDB" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
