Re: Check for certain changes in @PreUpdate listener class

Hi Hugi,

I think you can use similar mechanics to examine relationship data, too.  I
just didn't do that there.


On Thu, Jul 16, 2020 at 3:46 AM Hugi Thordarson <[email protected]> wrote:

> Thanks Michael! This works excellently for attributes on the entity, but
> I've yet to find a good solution when dealing with FKs (when to-one
> relationships are modified).
>
> I've opted to just don't update modificationDate when relationships are
> touched for now so… At least halfway there :).
>
> Thanks,
> - hugi
>
>
>
> > On 13 Jul 2020, at 13:23, Michael Gentry <[email protected]> wrote:
> >
> > Hi Hugi,
> >
> > You might have to compare everything to be certain.  Here is something
> I've
> > used in the past (for Cayenne 3.x) which might be helpful:
> >
> >
> https://gist.github.com/mrg/4dce22b67175c27f4047#file-cayenneutils-java-L105
> >
> >
> > On Mon, Jul 13, 2020 at 9:11 AM Hugi Thordarson <[email protected]>
> wrote:
> >
> >> Hi all.
> >> Almost all of my objects have attributes called creationDate() and
> >> modificationDate(), these are populated in a listener attached to the
> >> DataDomain:
> >>
> >> https://gist.github.com/hugith/a40faae5529a1826d601515a9e8c5206
> >>
> >> Relatively simple and has served me well for the past few years. One
> thing
> >> has always irritated me though. This method of doing things means that
> if
> >> the only change to an object is to a to-many relationship,
> >> "modificationDate" will get updated (for example: User has a
> relationship
> >> user<-->>invoices, the user creates an invoice which is then added to
> his
> >> "invoices" relationship. modificationDate is then updated even if there
> was
> >> no logical change to the user itself).
> >>
> >> So, I'm wondering… Is there any good way in the listener to check what
> >> attributes have changed, so I can skip the update to modificationDate if
> >> the only changed properties are to-many relationships?
> >> I know I could implement a CommitLogListener and use the ChangeMap from
> >> there, but as you see I'm doing these updates before committing, making
> >> these changes a part of the same commit (which I'd much prefer to keep
> that
> >> way).
> >>
> >> Cheers,
> >> - hugi
>
>