Yes I would like to look into this. I would like to see this through to implementation actually. Although I have a number of challenges to doing so, not least of which the fact that my experience with OrientDb is limited to reading a few tutorials and implementing a hello world a couple of months ago.. lol.. But with a bit of guidance from the dev team to navigate the API I'm sure I can do it. But there is a lot of work to be done. I haven't even begun to consider unit testing. And there are many integration issues that need to be addressed. Along with some background cleanup processes that need to be built (e.g. updating old schema versioned records as part of other maintenance processes).
With regards to space savings I'm writing up a comparison now. The advantages are of course dependent on data structure. If you have a lot of fields with long names like 'update_time' and short values then the savings are significant. If you have a lot of fields with very long data like 'text_of_book' then not so much. I will make one comment which I hope is taken as constructive criticism. Although it may be somewhat exaggerated for me being so new to OrientDb, as a potential contributor I've found the level of documentation (at least in the parts of core I've had to touch) almost non-existent. I've had to resort to reading the code of pretty much every method I need to understand to work out what it does but because there are many huge methods this is very tedious and time consuming. I think if a big effort was put in to add method documentation to the internal API it would encourage new contributors. I've added bits to many projects before but the difficulty of working out what's going on inside Orient is an order magnitude higher than any project I've dealt with in the past. I'd love to see this improve and perhaps as I gain more understanding I will be able to do some of this work myself. It's a fantastic product and I've love to see it become an industry standard. This is a key strategic issue in achieving that goal IMHO. On 07/04/14 22:27, [email protected] wrote: > > Steve, > > I see you mention serialization of sub-elements as well. > > How much effort do you think it is to get this working for embedded > maps and do you see that as something you will look into? > > Regards, > -Stefan > > On Monday, 7 April 2014 12:25:33 UTC, [email protected] wrote: > > Hi, > > Do you have any rough estimation regarding how much space this > could save? > I know the question is very vague but I'm curious to know if you > have done any comparison at all. > > Luca; Are you able to prioritize this to take advantage of this > create work asap? > > Steve, again, thank you very much. > > Regards, > -Stefán > > On Monday, 7 April 2014 03:41:11 UTC, Steve Coughlan wrote: > > On 07/04/14 13:12, Steve wrote: > > For testing/debug it may be convenient to use a string data > > serialization format. Or if using compressedbits this field > may > > specify which compression algorithm or settings to use. > > I should add a caveat to this statement. As long is there is > not a > mismatch between whether the serializer serializes fixed > length fields > using the same fixed length. Some code changes would be > required to > allow for this although they would not be difficult to do. > > -- > > --- > 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.
