Re: Regression from 4.2-RC2 to 4.2-RC3
Hi Lon. I think this new fix is incompatible with meaningful PKs, where two ObjectIds could really represent different operations even if their snapshots are equal. And IIRC that is exactly your case. Will think if there's a good way to fix this. In the meantime you could just safely rollback to 4.2.RC1, there are no major issues fixed in RC2 (this one causing your troubles and the one about split path expressions). On Wed, Dec 14, 2022 at 10:46 AM Andrus Adamchik wrote: > > Correct, we fixed an issue with two identical join table records being > committed in certain cases with inheritance. I'll defer to Nikita to comment > on the effects on your case. > > Andrus > > > > On Dec 13, 2022, at 10:08 PM, Lon Varscsak wrote: > > > > My guess is the new logic in > > DefaultDataDomainFlushAction.mergeSameObjectIds with OpIdFactory has a > > flaw. It's a little above my paygrade to figure out why. 🤣 > > > > On Tue, Dec 13, 2022 at 1:44 PM Lon Varscsak wrote: > > > >> I have a pretty serious regression between these versions. I'm not 100% > >> sure what's going on yet, but figured I'd drop a note and see if anyone has > >> any thoughts. I have a situation where I remove all the objects in a > >> relationship, and then reinsert them (same PK). This has been working in > >> 4.2 for a while now (in production), but something changed that when it > >> goes to delete the objects in question it only deletes 1 of 4 of them, and > >> then tries to insert the same data again resulting in a PK constraint > >> violation. > >> > >> I vaguely remember there was some work that Nikita had to do to make this > >> work..but I have a bad memory. :) > >> > >> Also, I'm using the GraphBasedDbRowOpSorter, which is really required to > >> do anything meaningful with Sybase and its lack of deferred constraints. > >> idk if this could be related...but it's been an issue before. > >> > >> Thanks, > >> > >> Lon > >> > -- Best regards, Nikita Timofeev
Re: Regression from 4.2-RC2 to 4.2-RC3
> where two ObjectIds could really represent different operations even if their > snapshots are equal. Ah, this is what it is. I was wondering how a seemingly logical and clean fix could've broken anything :) > On Dec 14, 2022, at 1:17 PM, Nikita Timofeev > wrote: > > Hi Lon. > > I think this new fix is incompatible with meaningful PKs, where two > ObjectIds could really represent different operations even if their > snapshots are equal. And IIRC that is exactly your case. > Will think if there's a good way to fix this. In the meantime you > could just safely rollback to 4.2.RC1, there are no major issues fixed > in RC2 (this one causing your troubles and the one about split path > expressions). > > On Wed, Dec 14, 2022 at 10:46 AM Andrus Adamchik wrote: >> >> Correct, we fixed an issue with two identical join table records being >> committed in certain cases with inheritance. I'll defer to Nikita to comment >> on the effects on your case. >> >> Andrus >> >> >>> On Dec 13, 2022, at 10:08 PM, Lon Varscsak wrote: >>> >>> My guess is the new logic in >>> DefaultDataDomainFlushAction.mergeSameObjectIds with OpIdFactory has a >>> flaw. It's a little above my paygrade to figure out why. 🤣 >>> >>> On Tue, Dec 13, 2022 at 1:44 PM Lon Varscsak wrote: >>> I have a pretty serious regression between these versions. I'm not 100% sure what's going on yet, but figured I'd drop a note and see if anyone has any thoughts. I have a situation where I remove all the objects in a relationship, and then reinsert them (same PK). This has been working in 4.2 for a while now (in production), but something changed that when it goes to delete the objects in question it only deletes 1 of 4 of them, and then tries to insert the same data again resulting in a PK constraint violation. I vaguely remember there was some work that Nikita had to do to make this work..but I have a bad memory. :) Also, I'm using the GraphBasedDbRowOpSorter, which is really required to do anything meaningful with Sybase and its lack of deferred constraints. idk if this could be related...but it's been an issue before. Thanks, Lon >> > > > -- > Best regards, > Nikita Timofeev
Re: Regression from 4.2-RC2 to 4.2-RC3
Thanks guys...yeah, I rolled back and am going again. Let me know if I can help test a fix. -Lon On Wed, Dec 14, 2022 at 5:18 AM Nikita Timofeev wrote: > Hi Lon. > > I think this new fix is incompatible with meaningful PKs, where two > ObjectIds could really represent different operations even if their > snapshots are equal. And IIRC that is exactly your case. > Will think if there's a good way to fix this. In the meantime you > could just safely rollback to 4.2.RC1, there are no major issues fixed > in RC2 (this one causing your troubles and the one about split path > expressions). > > On Wed, Dec 14, 2022 at 10:46 AM Andrus Adamchik > wrote: > > > > Correct, we fixed an issue with two identical join table records being > committed in certain cases with inheritance. I'll defer to Nikita to > comment on the effects on your case. > > > > Andrus > > > > > > > On Dec 13, 2022, at 10:08 PM, Lon Varscsak > wrote: > > > > > > My guess is the new logic in > > > DefaultDataDomainFlushAction.mergeSameObjectIds with OpIdFactory has a > > > flaw. It's a little above my paygrade to figure out why. 🤣 > > > > > > On Tue, Dec 13, 2022 at 1:44 PM Lon Varscsak > wrote: > > > > > >> I have a pretty serious regression between these versions. I'm not > 100% > > >> sure what's going on yet, but figured I'd drop a note and see if > anyone has > > >> any thoughts. I have a situation where I remove all the objects in a > > >> relationship, and then reinsert them (same PK). This has been > working in > > >> 4.2 for a while now (in production), but something changed that when > it > > >> goes to delete the objects in question it only deletes 1 of 4 of > them, and > > >> then tries to insert the same data again resulting in a PK constraint > > >> violation. > > >> > > >> I vaguely remember there was some work that Nikita had to do to make > this > > >> work..but I have a bad memory. :) > > >> > > >> Also, I'm using the GraphBasedDbRowOpSorter, which is really required > to > > >> do anything meaningful with Sybase and its lack of deferred > constraints. > > >> idk if this could be related...but it's been an issue before. > > >> > > >> Thanks, > > >> > > >> Lon > > >> > > > > > -- > Best regards, > Nikita Timofeev >