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 >> >>
