> > > Slightly different issue I think. I wasn't clear I was actually talking > versioning of individual class schemas rather than global schema version. > This is the part that allows to modify schema and (in some cases) avoid > having to scan/rewrite all records in the class. Although this is a nice > feature to have it's really quite a seperate problem from binary > serialization so I decided to treat them as seperate issues since trying to > deal with both at once was really bogging me down. Looking at your issue > though I'd note that my subsclasses of OClassImpl and OPropertyImpl are > actually immutable once constructed so this might help the schema-wide > immutability. >
Good, this would simplify that issue. > Also realised that per record compression will be rather easy to do... >> But that's in the extras bucket so will leave that as a bonus prize once >> the core functions are sorted and stable. >> > > We already have per record compression, what do you mean? > > > I wasn't aware of this. Perhaps this occurs in the Raw database layer of > the code? I haven't come across any compression code. If you already have > per record compression does this negate any potential value to per field > compression? i.e. if (string.length > 1000) compressString() > We compress at storage level, but always, not with a threshold. This brings to no compression benefits in case of small records, so compression at marshalling time would be preferable: drivers could send compressed records to improve network I/O. Lvc@ -- --- 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.
