[Django] #29841: Fixtures counting backward
Django
-------------------------------------+-------------------------------------
Reporter: Victor | Owner: nobody
Porton |
Type: New | Status: new
feature |
Component: Database | Version: 2.1
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 0
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29841>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: closed
Component: Database layer | Version: 2.1
(models, ORM) |
Severity: Normal | Resolution: invalid
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => invalid
Comment:
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.
[https://docs.djangoproject.com/en/stable/internals/contributing/bugs-and-
features/#reporting-bugs-and-requesting-features Rely on a different
support channel or search trough the documentation instead].
--
Ticket URL: <https://code.djangoproject.com/ticket/29841#comment:1>
Django
-------------------------------------+-------------------------------------
Component: Database layer | Version: 2.1
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: invalid =>
Comment:
Your solution works only for testing.
But I may want to use fixtures to set up a production server.
--
Ticket URL: <https://code.djangoproject.com/ticket/29841#comment:2>
Django
-------------------------------------+-------------------------------------
Component: Database layer | Version: 2.1
(models, ORM) |
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => invalid
Comment:
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
--
Ticket URL: <https://code.djangoproject.com/ticket/29841#comment:3>
Django
-------------------------------------+-------------------------------------
Component: Database layer | Version: 2.1
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: invalid =>
Comment:
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).
--
Ticket URL: <https://code.djangoproject.com/ticket/29841#comment:4>
Django
-------------------------------------+-------------------------------------
Component: Database layer | Version: 2.1
(models, ORM) |
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => invalid
Comment:
Use the [https://docs.djangoproject.com/en/stable/ref/databases/#manually-
specifying-values-of-auto-incrementing-primary-keys 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29841#comment:5>
Django
-------------------------------------+-------------------------------------
Component: Database layer | Version: 2.1
(models, ORM) |
Severity: Normal | Resolution:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: closed => new
* resolution: invalid =>
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29841#comment:6>
Django
-------------------------------------+-------------------------------------
Type: New feature | Status: new
Component: Database layer | Version: 2.1
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage:
| Unreviewed
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29841#comment:7>
Django
-------------------------------------+-------------------------------------
Component: Database layer | Version: 2.1
(models, ORM) |
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
* status: new => closed
* resolution: => wontfix
Comment:
Hi Victor.
I'm going to close this again. Please don't just reopen it. From
[https://docs.djangoproject.com/en/dev/internals/contributing/triaging-
tickets/#closing-tickets 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,
which 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!
--
Ticket URL: <https://code.djangoproject.com/ticket/29841#comment:8>