I am actually glad we went on a tangent and started discussing UUIDs. I just ran into a use-case of an idempotent PUT API endpoint that takes a mix of new and existing objects, and there's no natural key in the entity to check whether new (PK-less) objects are already in DB (so that we UPDATE them instead of INSERT). UUID would come in handy in this situation :)
(FWIW, the endpoint is running on Agrest with Cayenne underneath, and Agrest is the layer that ensures idempotent semantics). Andrus > On Aug 20, 2024, at 12:01 PM, Hugi Thordarson <h...@godurkodi.is> wrote: > > Judging from some very, very basic experimentation, Cayenne seems to do fine > with UUID PKs. > > Db generated UUIDs really just work like serial integers with a different > generated value type: > > https://github.com/hugithordarson/xx-c42/blob/main/src/main/java/family/MainUUIDDbGenerated.java > > …and the fun stuff, app generated UUID PKs (for all your cross- back- and > forth-referencing insertion needs) look fine as well: > > https://github.com/hugithordarson/xx-c42/blob/main/src/main/java/family/MainUUIDAppGenerated.java > > …although I wouldn't vouch for that PK-generation method of exposing the PK > and populating it in a post-add hook. > > Unfortunately h2 doesn't appear to support deferred constraints, but I tested > this against postgres with the constraints present. > > Anyway, pardon this tangent, born from a joke. I won't really say this really > demonstrates much, but it was at least a fun experiment over lunch and > thought you might enjoy it:). > > Cheers, > - hugi > > >> On 16 Aug 2024, at 17:26, Michael Gentry <blackn...@gmail.com> wrote: >> >> 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 >>>>> >>>>> >>> >>> >
