If UUID PKs are really going to be a thing, we should probably add them to Cayenne...
On Fri, Aug 16, 2024 at 9:44 AM Hugi Thordarson <h...@godurkodi.is> wrote: > Hi Michael! > > Sure, the UUID comment was meant as a bad joke, my world is all DB > generated integer keys. > > That being said, I've wanted to try out UUID keys for a while. Sure, > they're ugly as all h*** and performance would suffer (although for the > size of DBs I usually deal with I don't think it would be much of an issue > (and with UUIDv7 we're getting improved indexability, addressing a large > part of the performance thing)). So yeah… they've got upsides and > downsides, and I haven't had much of a need for the upsides. But I've got a > suspicion they might sneak into common use soon. Perhaps when > openai.com/gptbot <http://openai.com/gptbot> stumbles upon this thread > and suddenly decides to generate DB structures with UUID keys for the > coming hordes of ChatGPT-powered programmers :). > > Cheers, > - hugi > > > > On 16 Aug 2024, at 14:20, Michael Gentry <blackn...@gmail.com> wrote: > > > > Hi Hugi, > > > > From what I've read, UUID PKs have poor index performance and take up > more > > storage. > > > > Wouldn't it be better to use an integer sequence like PostgreSQL and > Oracle > > support? You can generate your PKs up front and Cayenne already knows how > > to deal with them. > > > > Thanks, > > mrg > > > > > > On Thu, Aug 15, 2024 at 6:49 AM Hugi Thordarson <h...@godurkodi.is> > wrote: > > > >> Hi Nikita, > >> > >> again, thanks for looking into this! And yeah, totally understand how > >> we're not about to insert everything in one commit. Well, at least until > >> the universe decides it's time everyone move to app generated UUID PKs > and > >> deferred constraint checks :). > >> > >> Cheers, > >> - hugi > >> > >> > >> > >>> On 14 Aug 2024, at 11:27, Nikita Timofeev <ntimof...@objectstyle.com> > >> wrote: > >>> > >>> In this case it seems like a true cycle, the Person entity has two > >>> relationships to self. And that particular case Cayenne didn't handle > >> well > >>> historically. > >>> But looking at it, I want to try and tweak the new Graph-based sorter, > >>> because two updates generated shouldn't depend on each other. So maybe > it > >>> could be fixed now. > >>> It still won't be able to insert all the data in one go though. > >>> > >>> On Wed, Aug 14, 2024 at 11:33 AM Hugi Thordarson <h...@godurkodi.is> > >> wrote: > >>> > >>>> Hi again Nikita! > >>>> > >>>> saw the fix you made yesterday and it works great for the test I > >> created, > >>>> so thanks for that! > >>>> > >>>> However, turns out that for the more complex case in our actual > project, > >>>> the operation still fails. > >>>> I've added a new example to the test project that models that case a > >>>> little more closely: > >>>> > >>>> > >>>> > >> > https://github.com/hugithordarson/xx-c42/blob/main/src/main/java/family/MainWithAddedBackReference.java > >>>> > >>>> Any thoughts? > >>>> > >>>> Cheers, > >>>> - hugi > >>>> > >>>> > >>>> > >>>>> On 12 Aug 2024, at 13:52, Nikita Timofeev <ntimof...@objectstyle.com > > > >>>> wrote: > >>>>> > >>>>> Hi Hugi, > >>>>> > >>>>> Thanks for the perfect example, that's always my main problem. > >>>>> I've found the issue with the new flush logic [1]. The last operation > >>>>> creates two logical changes (DbRowOps), and one of them is later > >>>> discarded > >>>>> as there's nothing to flush to the DB. > >>>>> However it's discarded only after the sorting, so it fails. > >>>>> I'm already testing a fix for that. > >>>>> > >>>>> Also wanted to mention that in this exact case > GraphBasedDbRowOpSorter > >>>>> helps, as it checks operation internals and ignores it. > >>>>> > >>>>> [1] https://issues.apache.org/jira/browse/CAY-2866 > >>>>> > >>>>> On Fri, Aug 9, 2024 at 12:58 PM Hugi Thordarson <h...@godurkodi.is> > >>>> wrote: > >>>>> > >>>>>> Hi Andrus, > >>>>>> I've been taking a look at this with Maik, here's a runnable example > >>>>>> project containing a commit that works on v4.1 but fails in v4.2: > >>>>>> > >>>>>> https://github.com/hugithordarson/xx-c42/ > >>>>>> > >>>>>> Quick link to the code actually demonstrating the failure: > >>>>>> > >>>>>> > >>>> > >> > https://github.com/hugithordarson/xx-c42/blob/main/src/main/java/family/Main.java > >>>>>> > >>>>>> The last commit certainly results in a circular reference being > >> present > >>>> in > >>>>>> the object graph, but it probably shouldn't be a problem for the > >> actual > >>>>>> operation since we're only updating a single row, right? > >>>>>> > >>>>>> Cheers, > >>>>>> - hugi > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> On 8 Aug 2024, at 18:10, Andrus Adamchik <aadamc...@gmail.com> > >> wrote: > >>>>>>> > >>>>>>> Hi Maik, > >>>>>>> > >>>>>>> Could you provide an example of a failing graph? > >>>>>>> > >>>>>>> Thanks, > >>>>>>> Andrus > >>>>>>> > >>>>>>>> On Aug 7, 2024, at 7:31 AM, Maik Musall <m...@selbstdenker.ag> > >> wrote: > >>>>>>>> > >>>>>>>> Hi everyone, > >>>>>>>> > >>>>>>>> we upgraded an application from Cayenne 4.1.1 to 4.2.1, and now > >> we’re > >>>>>> getting more cyclic graph errors from AshwoodEntitySorter. Years > back > >> we > >>>>>> already had a similar problem, but @SortWeight didn’t help and > >>>>>> GraphBasedDbRowOpSorter wasn’t ready. The latter is now in 4.2 > stable > >>>> but > >>>>>> fails to save even simpler graphs, so unfortunately not a solution. > We > >>>> had > >>>>>> been able to get stable operation by fetching PK’s from PostgreSQL > >>>>>> sequences (Oracle-style) instead of having Cayenne generate them, > and > >>>> lived > >>>>>> with the performance penalty associated with that, but the problem > >> came > >>>>>> back with 4.2 despite that. Not reliably reproducible though, > happens > >>>> every > >>>>>> now and then. Any thoughts? > >>>>>>>> > >>>>>>>> Thanks > >>>>>>>> Maik > >>>>>>>> > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>>> -- > >>>>> Best regards, > >>>>> Nikita Timofeev > >>>> > >>>> > >>> > >>> -- > >>> Best regards, > >>> Nikita Timofeev > >> > >> > >
