On 2016-08-17 18:06, Mike Nimer wrote:
This reminds me of a system I worked on years ago that had a similar
problem and solved it with a side table. It would store the object in the
DB as XML (I told you it was long time ago) and then we had a table on the
side that stored each property in a row, if it's was marked as indexed.
The full XML object gave us quick read access. The side table allowed us to
write complex sql to find objects. Although I will say the sql could get
nasty with this table structure, lot's of self-referencing joins.
This might be crazy, but what if oak did something similar? The current
data could still be stored as a JSON object, like it is now, as the source
of truth. And then an Async task could be used update the side table with
all properties or only indexed properties of each node. This could be
disabled for very large implementations or you could flip a flag to store
all revisions or only the latest. This table could even be considered
temporary and rebuilt as needed.
With that said, the new JSON support being added to the different databases
looks very promising and might solve the same problem.
--mike
Yes, I once worked in a project with a similar design.
What you might miss is that we actually (currently) do not need to index
anything additionally, as JCR/OAK indexes are handled by a layer above
the DocumentStore - whether *that* is something that should reviewed
would be an interesting discussion as well.
Best regards, Julian
