Hi, Has something newsworthy happened on this? :)
Best regards, -Stefán On Friday, 18 April 2014 13:57:07 UTC, Lvc@ wrote: > > >> 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.
