Hi, This is good news, now lets hope Luca can find resources for this soon.
Regards, -Stefán On Wednesday, 14 May 2014 11:10:55 UTC, Steve Coughlan wrote: > > 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] <javascript:> 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] <javascript:>. > 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.
