Hi Tomek, I like the idea (agree with Vikas’ comments / cautions as well).
You are hinting at expected performance differences (maybe faster or slower than the current approach). That would probably be worthwhile to investigate in order to assess your idea. One more (hypothetical at this point) advantage of your approach: we could utilise DB-native indexes as a replacement for property indexes. Cheers Michael On 16/08/16 07:42, "Tomek Rekawek" <[email protected]> wrote: >Hi Vikas, > >thanks for the reply. > >> On 16 Aug 2016, at 14:38, Vikas Saurabh <[email protected]> wrote: > >> * It'd incur a very heavy migration impact on upgrade or RDB setups - >> that, most probably, would translate to us having to support both >> schemas. I don't feel that it'd easy to flip the switch for existing >> setups. > >That’s true. I think we should take a similar approach here as with the >segment / segment-tar implementations (and we can use oak-upgrade to convert >between them). At least for now. > >> * DocumentNodeStore implementation very freely touches prop:rev=value >> for a given id… […] I think this would get >> expensive for index (_id+propName+rev) maintenance. > >Indeed, probably we’ll have to analyse the indexing capabilities offered by >different database engines more closely, choosing the one that offers good >writing speed. > >Best regards, >Tomek > >-- >Tomek Rękawek | Adobe Research | www.adobe.com >[email protected]
