I strongly believe that when your data has a temporal nature you should
model this in your domain layer.
Just my two cents.
Cheers,
Jeroen
On 19 March 2017 at 19:37, Kevin Meyer wrote:
> This got caught in my spam folder...
>
> I fully understand your desire for deep clone in the persistence l
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.
Cheers,
Kevin
On Tue, March 14, 2017 05:31, David Tildesley wrote:
> Thanks Kevin,
> I g
Thanks Dan.
On Tuesday, 14 March 2017 6:09 PM, Dan Haywood
wrote:
Meant to post an opinion on this.
My thought was to store the object graph as a jaxb / xml ; these are then
easy to clone and are also view models automatically.
Downside to this design is handling changes to the struc
Meant to post an opinion on this.
My thought was to store the object graph as a jaxb / xml ; these are then
easy to clone and are also view models automatically.
Downside to this design is handling changes to the structure of these over
time... Anyway backward breaking change would be problematic
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, "ke...@kmz.co.za"
wrote:
Hi David,
Did you find a solution?
Just
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
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 si
