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 <h...@karlmenn.is> 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 <blackn...@gmail.com> 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 <h...@karlmenn.is> > 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 > >
