Considering the number of people using Oracle is small, and those using the non-default for use_returning_into should be smaller, and that it sounds like the sequence naming logic doesn't sound super different, and that 1.11 hasn't been out for *that* long, relatively, it sounds like option 1 is the best to me. You should also be able to catch these users with a system check so show them an error if/when they upgrade to the patch release containing the warning. But I've no experience with any of these pieces of code I'm afraid, I'm just trying to keep the ball rolling here :)
On 9 August 2017 at 18:28, Kevin Grinberg <ke...@activefrequency.com> wrote: > Hi folks, > > I'm looking for input on https://code.djangoproject.com/ticket/28451 > > Basically, the root of the issue is that a change introduced in 1.11 > breaks Oracle sequence names under certain conditions (if you have > use_returning_into = False, which is *not* the default). The symptom is > that if you had a pre-1.11 project using Oracle and use_returning_into = > False, then after upgrading to 1.11 INSERTs that need an autoincrement will > fail. > > The regression appears to be an unintentional side effect of > https://github.com/django/django/commit/69b7d4b116e3b70b250c77829e1103 > 8d5d55c2a8 > > In theory, I think just the breaking piece could be reverted without > affecting the issue that the patch addressed (which I believe was quoting). > The problem is that, as far as I can tell, the options boil down to: > > 1) Revert the "_SQ" change and break things for users who started new > projects on 1.11 (to be clear - the subset that's using Oracle and > use_returning_into = False). > > 2) Leave it alone and provide a warning and migration path for pre-1.11 > projects to convert their sequence names to the "new" style (possibly in an > automatic migration?) > > I don't recall breaking changes in a dot-release for anything other than a > security issue, which this is not (and feels particularly crappy to do for > an LTS). On the other hand, this is a pretty nasty regression (for the > admittedly small subset of users). > > Either way, it seems like the best solution from a user perspective would > involve scripts for automatically renaming the sequences, which scares me a > bit in terms of how fragile they're likely to be. > > Perhaps there's another, more elegant, option? Have we had a similar > problem with other backends at some point in the past that we can look to > in terms of a template? > > Thanks, > Kevin > > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To post to this group, send email to django-developers@googlegroups.com. > Visit this group at https://groups.google.com/group/django-developers. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/django-developers/b379e41b-4d5a-457d-9708- > 1bbd40aba9c7%40googlegroups.com > <https://groups.google.com/d/msgid/django-developers/b379e41b-4d5a-457d-9708-1bbd40aba9c7%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM3tgZLv-YKpLXTA25DB_ooaHKsRnq8z_MJO8QuACNyTGQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
