isis-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Meyer" <>
Subject Re: Deep copy object graph
Date Sun, 19 Mar 2017 18:37:37 GMT
This got caught in my spam folder...

I fully understand your desire for deep clone in the persistence layer -
laziness is a respectable reason!

Let us know if you find something that works for you, please.


On Tue, March 14, 2017 05:31, David Tildesley wrote:
> Thanks Kevin,
> I guess I was looking for something like deep clone using serialization
> rather than detach-clone-persist and so on through the object graph.
> Being lazy ;)
> Regards,David.
> On Tuesday, 14 March 2017 4:07 PM, "" <>
> wrote:
> Hi David,
> Did you find a solution?
> Just a question: Why would you not use a standard service action to
> create the copy? Is there any reason why you want Datanucleus to do it?
> Personally, I would try and use a service that creates a copy of the
> current records and updates the public reference instance to always point
> to the latest (perhaps use a Proxy, for example - and another
> administrative view that displays the full set of changes over time).
> Cheers,
> Kevin
> On 2017-03-08 06:05, David Tildesley wrote:
>> Hi,
>> I have a need to keep public records and to be able to edit objects
>> and put them through a publishing lifecycle whilst public can view the
>> current record without seeing the changes. Temporal object pattern [1]
>> seems like the simplest pattern. Then it comes down to how hard or easy
>> it is to simply  copy a components entire object graph to make a new
>> version (don't really care about the duplication of data that hasn't
>> change from version to version). Datanucleus has some support for coping
>> an object graph from one repository to another - I assume you can copy
>> to the same repository to achieve what I want to do. Krypo [2] seems like
>> it is being used by Datanucleus. Anyways - how to do this with ISIS? Any
>> suggestions appreciated. Some context:
>> A Building (component)  has a current FireSafetyCertification
>> (component) and is published as a public record and these records are
>> kept for 10 years. A change to a record that is viewable by the public is
>> regarded as a new public record. Overtime (slowly) these
>> FireSafetyCertificates may expire/withdrawn/change in detail. But when
>> they are published they constitute a public record. Building has names,
>> addresses, images, parts, construction details, etc. whilst
>> FireSafetyCertification has documents, exemption notices, expiry dates
>> etc.  Using the Temporal Object pattern, a Building object has 1..*
>> BuildingVersion and all of the Building's detail hangs off
>> BuildingVersion. 
>> Any other suggestions instead of Temporal Object pattern also
>> appreciated.
>> [1] 
>> [2]
>> Thanks!
>> David.

Kevin Meyer
Ljubljana, Slovenia

View raw message