Hi Maximiliano, Michael Thanks for the clarification.
I'm not 100% up to speed with the new migrations code, but I agree that this looks odd; it's certainly worth opening a ticket so that the issue isn't forgotten. It's even arguable that this might be a 1.7 blocker; even though it isn't a problem with "official" database backends, if we're serious about supporting third party backends, we shouldn't publish a test suite that we know they can't run. Yours, Russ Magee %-) On Tue, May 20, 2014 at 7:30 PM, Maximiliano Robaina <maxiroba...@gmail.com>wrote: > Hi Michel, > > Thank to explain it better than me. > > Regards. > > El martes, 20 de mayo de 2014 00:42:35 UTC-3, Michael Manfre escribió: >> >> Hi Russell, >> >> I understand what Maximiliano is asking. It's a flaw with >> SchemaTests.delete_tables [1] and it is essentially doing a raw drop table, >> instead of using the 3rd party backend friendly SchemaEditor.delete_model >> [2]. There was the last time I checked (and still exists) a lot of raw SQL >> in the schema tests that caused tests to fail for django-mssql. It appears >> other non-core backends are also facing these issues. >> >> Regards, >> Michael Manfre >> >> [1] https://github.com/django/django/blob/stable/1.7.x/ >> tests/schema/tests.py#L38 >> [2] https://github.com/django/django/blob/stable/1.7.x/ >> django/db/backends/schema.py#L274 >> >> >> On Mon, May 19, 2014 at 10:45 PM, Russell Keith-Magee < >> rus...@keith-magee.com> wrote: >> >>> >>> On Tue, May 20, 2014 at 7:07 AM, Maximiliano Robaina <maxir...@gmail.com >>> > wrote: >>> >>>> Hi, >>>> >>>> Running tests, (I'm using firebird) in schema app, I see that the >>>> tearDown method deletes all tables created by each test. The problem here >>>> is for tables with AutoInc field where sequences are created independently, >>>> when the table is dropped we need delete the sequence object too. >>>> The, to me, customized delete_model method from schema editor do that, >>>> when the model is deleted, then the sequence is deleted if any. >>>> >>>> So, the delete_tables method used in tearDown, needs to delete the >>>> correlated sequences either calling to drop_sequence_sql from >>>> DatabaseOperations or implementing something in Schema editor. >>>> >>>> Hi Maximiliano, >>> >>> It's not clear (to me, at least) what you're asking for here. >>> >>> In the general case, resetting sequences *shoudn't* be needed as part of >>> a test suite. Tests that are dependent on a specific PK value being >>> allocated are wrong by design, because you simply can't guarantee >>> allocation order in a database. >>> >>> If you've got a specialist sequence being used as a part of a particular >>> model, then you might need to have some custom code to reset particular >>> sequences… but then, you're dealing with a custom scenario, in which case I >>> don't think it's unreasonable to require some custom reset code as part of >>> your test. >>> >>> If this is a Firebird specific issue, then it isn't clear to me why the >>> statements you need can't be integrated into the flushing infrastructure >>> that is already in place. In all the built-in backends, the tearDown method >>> on tests doesn't *delete* tables, it flushes them; sequences are reset as >>> part of that process. If Firebird requires something extra, you're going to >>> need to give us a specific proposal for a database API modification that >>> would meet your needs. >>> >>> Yours, >>> Russ Magee %-) >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> To post to this group, send email to django-d...@googlegroups.com. >>> >>> Visit this group at http://groups.google.com/group/django-developers. >>> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/django-developers/CAJxq84-Nu9gVDdwJWGu- >>> LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com<https://groups.google.com/d/msgid/django-developers/CAJxq84-Nu9gVDdwJWGu-LuEoSpUCQyY2KWN1Kt5o9YquejURyw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Django developers" 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 http://groups.google.com/group/django-developers. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/1e76f781-48b3-4ae2-b2de-3e3f8d0e21f1%40googlegroups.com<https://groups.google.com/d/msgid/django-developers/1e76f781-48b3-4ae2-b2de-3e3f8d0e21f1%40googlegroups.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Django developers" 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84-y%3D9G3T4%2BNmJKObOva9hPW%3D-uBuK19CnyXY%2BUQ%2BQ2epw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
