Hi Stefan, Progress has been slow although as I ran into the usual issue, got bogged down in issues, became obsessed, ended up spending far more time than I expected, got it the shit from my employer for neglecting my work, panicked to catch up, never got back to it ;)
However I did push an update a couple of days ago. Although many of the extra's have not been addressed I'm now able to persist a binary record inside orientdb in and retrieve it after a restart (proving that it's deserialized from disk not from cache). Which implies also being able to persist the drstically altered schema structure. Since I had made the field-level serializer pluggable I've been a jackson-json as the serialization mechanism for easy debugging. Now I need to adjust the existing ODB binary serializers. They all embed data-length in the serialized data, which we don't need to do since we store it in headers. And I've adjusted the interface slightly. So I just need to massage the existing binary serializers a little to fit the new interface and we will be back to full binary serialization. So... some progress, no where near as much as I'd hoped but now that it actually works inside ODB (before we could only serialize/deserialize to byte arrays using dummy schema objects) I believe it's at a point where we can get other ODB developers involved to review/test/contribute. I've just noticed a post Luca made a while back that I missed that he'd employed someone who'll be focussed on this so I hope we can work together on the rest of the integration. Honestly integration has been the hardest part. I've learned an awful lot about the internals of ODB the hard way (apologies for blunt comment but the documentation is awful and it's very hard to distinguish what is internal/public API) and also learned I've probably only touched a tiny fraction of it. On 14/05/14 19:40, [email protected] wrote: > 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] > <mailto:[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.
