Hi,
Am 06.04.2017 um 15:54 schrieb Hilaire <hilaire@drgeo.eu>:
Hi,
Here is another scenario where I have trouble with Voyage:
Let's an object A, with an attribute an object Address. Then I create B, a copy of A.
Of course the object Address is both an attribute of A and B. (no deep copy).
As long as my Voyage repo is running, editing Address from A or B is doing fine: when editing Address from A, I can see this reflected in B's Address, as expected.
Sadly, this Object scheme is lost in the persistency: when I reset the repo, shutdown it, restart it, to force a full retrieve from the Mongo repo, object A and B do not share anymore the Address object has it should be.
I understand Voyage is not a true really Object Oriented repository, but is it possible to overcome such limitation?
The Adress object must voyageRoot in order for this to work. If an object is voyageRoot it is kept as identity being a separate object living in a collection that can be referenced. If it is not voyageRoot you store a copy of the object each them because that object gets embedded into the container object.
One idea will be to have collection of Address, but this really looks strange to me.
why?
I think Fuel was doing just fine with such scenario, but sadly Fuel is not reliable between images.
Fuel stores the object graph as it is. It is hard to compare because you cannot search a fuel dump. I think the question is what you need. If it is having a partial graph in memory that has been extracted from the whole graph through query then you have a pretty decent need for a database and a tool like voyage. If you just need to persist you are better off with fuel. And if you need the same to be reliable between two images use STON.
Thanks to read up to here.
You're welcome! :) Norbert
Hilaire
-- Dr. Geo http://drgeo.eu