Voyage and attributes references

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?

One idea will be to have collection of Address, but this really looks
strange to me.

I think Fuel was doing just fine with such scenario, but sadly Fuel is
not reliable between images.

Thanks to read up to here.

Hilaire

--
Dr. Geo
http://drgeo.eu

Hi,
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
>
>

Le 06/04/2017 à 16:14, Norbert Hartl a écrit :
>> One idea will be to have collection of Address, but this really looks
>> strange to me.
>>
> why?
>

It looks like a painful scenario: Address is most of the time referenced
by only one object, but in one scenario I need a shared attributes.
Because of this it implies to overlook for #save and #remove messages to
Address instances all around, forgetting some leading to bugs. But there
are not alternative I guess? Or to have two Address class, one set as a
root. Not sure what is the best practice.

Hilaire

--
Dr. Geo
http://drgeo.eu

Not sure either. But I think having a SharedAddress class is worth a try. The other possibility would be if #voyageRoot would be also instance side. Right now I don't have a computer to check.

Norbert
> Hilaire
>
> --
> Dr. Geo
> http://drgeo.eu
>
>