Fixtures counting backward

[Victor Porton]

I have this problem: ​https://stackoverflow.com/q/52709119/856090

I want a table to hold both models from fixtures and models generated dynamically by my Python code.

If I add a new fixture record and then run loaddata it may overwrite one of the dynamically created objects!

I also need to have fixed (not autogenerated) primary keys in order to refer to object from the fixture from my Python code.

My suggestion:

Assign to the fixture objects primary keys like 2**31 - 1, 2**31 - 2, 2**31 - 3 etc. Then the "dynamically created" objects won't be overwritten by loaddata.

However I do not know how autoincrement value will behave in this situation.

Please add features to make it possible.

[Simon Charette]

Hello there, you should be able to achieve what you're after by using TransactionTestCase.fixtures, setUp(), and reset_sequences.

• ​https://docs.djangoproject.com/en/stable/topics/testing/tools/#django.test.TransactionTestCase.fixtures
• ​https://docs.djangoproject.com/en/stable/topics/testing/advanced/#django.test.TransactionTestCase.reset_sequences

Please refrain from using this bug tracker as a second tier support channel. It's not because you're not getting feedback 2 days after asking a question on Stackoverflow that the features you are looking for do not already exist. ​Rely on a different support channel or search trough the documentation instead.

[Victor Porton]

Your solution works only for testing.

But I may want to use fixtures to set up a production server.

[Simon Charette]

Dear Victor,

As I said in my previous comment this isn't a second tier support channel.

There's plenty of ways to bootstrap initial data for your app and I'd suggest you begin by having a look at the documentation.

• ​https://docs.djangoproject.com/en/2.1/howto/initial-data/#providing-initial-data-for-models
• ​https://docs.djangoproject.com/en/2.1/topics/migrations/#data-migrations

[Victor Porton]

I have not asked for support.

I asked for a feature:

I want 2**31-1, 2**31-2, 2**31-3, etc. PKs for fixtures to work.

I suspect it won't work now because of setting wrong autoincrement. This needs to be worked around (e.g. add a way to specify an autoincrement value in fixture directly).

[Tim Graham]

Use the ​sqlsequencereset command and run that SQL. It's not clear to me that some change in Django is required. If you have a more concrete proposal, feel free to offer it.

[Victor Porton]

I am dissatisfied with your solution.

First, it prints SQL code, while I need to execute it. I need to write custom code which would execute this SQL, in order to be able to execute it portable for any Django installation. I should not have to write such code, it should be builtin in Django (or at least in some Django extension).

Second (more importantly), it prints SQL to reset counters in all models of an app. I need to reset it only in one model, not all models. Again I can manually extract this code from sqlsequencereset output. It is manual work, all it should be done automatically and portably.

Third, I want the counter to be reset automatically every time a certain fixture is loaded. The fixture and its autoincrement are one object not two. (Loading one without other creates inconsistent data, hard to debug.) They should be done together. We should devise a backward-compatible syntax of fixtures to store the counter in the fixture file.

So I have three(!) reasons not to close the bug. I am reopening it again.

[Tim Graham]

If you want to write some code to solve the problem, we can take a look to see if it's suitable for inclusion in Django. I don't think the use case is common enough to say "yes, this is definitely something that Django should solve and it can't be done in a third-party app."

I would close the ticket again as wontfix, but I'll leave it for another person to "third" this decision after Simon and me.

[Carlton Gibson]

Hi Victor.

I'm going to close this again. Please don't just reopen it. From ​the Contributing Guide on Closing Tickets:

Always use the mailing list to get a consensus before reopening tickets closed as “wontfix”.

See also TicketClosingReasons/DontReopenTickets.

If you want to push this forwards then you need to put together an email, with full examples that demonstrate your issue, explaining what you're trying to achieve and why you can't do it using the suggestions that Simon and Tim have already provided. It's only if you can convince a number of people there that you have a reasonable request that we will re-open this ticket.

(Both Simon and Tim are very reasonable people: they'd be the first to say so if you make a compelling case — but you would need to outline it fully in an email.)

I would advise you to give the suggestions a try. You'll probably find a working solution in a few lines of code. If you get stuck please use the support channels as requested. (See TicketClosingReasons/UseSupportChannels)

I'm sorry if this response doesn't meet your expectations. We must insist on this workflow though, or a project of Django's size simply isn't maintainable.
Good luck!