Excellent - thanks much.
On Aug 18, 2017, at 4:02 PM, knbk
<marten.k...@gmail.com<mailto:marten.k...@gmail.com>> wrote:
There are various reasons why you should never execute queries at startup. One
you've seen: it makes it impossible to migrate a new database. Other reasons
include that the choices are cached and are only renewed when the server
restarts, and that when running tests, the query is executed before the test
database is set up and will run on the main database.
The solution in this case is to use a ModelChoiceField[1], i.e.:
category = forms.ModelChoiceField(queryset=Category.objects.all(),
required=False)
This allows to pass in a queryset which is evaluated whenever the field is used
to make sure the values are up-to-date. Since querysets are lazy, this won't
execute any queries on startup.
[1] https://docs.djangoproject.com/en/1.11/ref/forms/fields/#modelchoicefield
On Saturday, August 19, 2017 at 12:14:48 AM UTC+2, subaru_87 wrote:
Here’s a “problem” with migrations that I’ve had. It only occurs on a first
time installation (like a first-time upload to Heroku, for example).
In forms.py, I have a field dependent upon a column in another table (Category):
category = forms.TypedChoiceField(required=False,
choices=[(category.pk<http://category.pk/>,
category.name<http://category.name/>) for category in Category.objects.all()])
Running makemigrations or migrate if there’s no pre-existing database with a
table named “Category” gives an error saying as much. However, I’m expecting
migrate to create the tables required. Therefore, it’s a catch-22.
Of course, the “easy” answer is to comment out the above code, add in:
category = forms.CharField(max_length=12)
And run the initial migrations. Then, turn around and comment out that same
code, uncomment the real code shown above, and run migrations again. It works,
but it seems a bit awkward.
Has anyone else had this issue? Or am I doing something wrong?
Thanks much,
Jim Illback
On Aug 18, 2017, at 1:21 AM, James Bennett <ubern...@gmail.com<javascript:>>
wrote:
On Thu, Aug 17, 2017 at 1:03 PM, Antonis Christofides
<ant...@djangodeployment.com<javascript:>> wrote:
Second, just to make things clear, the word "migration" has two meanings. The
original meaning of migration is to switch to another software system (e.g.
migrate from MySQL to PostgreSQL, or migrate a repository from subversion to
git). In Django, the term "migration" means something else: to update the
database to the new schema. In my opinion this terminology is wrong and
confusing (apparently it comes from Ruby on Rails, but I'm not certain), and a
better one would have been "dbupdate" or something, but since it's migration
we'll keep it and you'll have to understand which meaning is meant in each case.
An important thing worth knowing is that Django's migration framework does
*not* only track the database schema. It also tracks the state of the Python
classes which define the models, including options which do not affect the
underlying DB schema, and making such changes to a model will create the need
for a migration.
This is absolutely necessary, though, because the migration framework generates
a frozen snapshot of the state at each migration, so that you can access the
ORM to do things like data updates via the RunPython migration operator. If you
were to change, say, the default ordering of a model without also generating a
migration to record that change (even though it has no effect on the database
schema), you could run into trouble if you later removed a field referenced by
the old ordering, since one of the intermediate ORM snapshots would attempt to
order queries by a now-nonexistent column.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users...@googlegroups.com<javascript:>.
To post to this group, send email to djang...@googlegroups.com<javascript:>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/CAL13Cg_0p1pMtMR2y2eGry1UhQaSRpswntcnMWtHNdPgV1Ph9w%40mail.gmail.com<https://groups.google.com/d/msgid/django-users/CAL13Cg_0p1pMtMR2y2eGry1UhQaSRpswntcnMWtHNdPgV1Ph9w%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
django-users+unsubscr...@googlegroups.com<mailto:django-users+unsubscr...@googlegroups.com>.
To post to this group, send email to
django-users@googlegroups.com<mailto:django-users@googlegroups.com>.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/d878688d-00a3-452d-8cb8-956dcf41a52e%40googlegroups.com<https://groups.google.com/d/msgid/django-users/d878688d-00a3-452d-8cb8-956dcf41a52e%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 users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-users/E4674811-1420-42CB-8804-69FB205310FA%40hotmail.com.
For more options, visit https://groups.google.com/d/optout.
