This is expected and by design. Because in the model where you define the
foreign key, you also don't define its type. The type is automatically resolved
through the column type from the target model.
Cheers
Markus
On Fri, Sep 2, 2022, at 10:39 AM, Manasvi Dobariya wrote:
> I have default prim
Yes, until April 2024: https://www.djangoproject.com/download/
On Tue, Nov 1, 2022, at 3:54 PM, Lakshyaraj Dash wrote:
> Is django 3.2 still supported?
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group
Hey Abraham,
to be more specific, when you used South and ran "manage.py
datamigration" [1] you got an empty migration file with a forwards and
backwards method where you had to fill out the blanks and tell South
what to do, e.g. to create a certain object in the database.
With Django's migration
ayes/django-migration-fixture,
> which is meant to provide a convenient wrapper around the initial_data
> fixtures (files). My PR with the changes mentioned above is viewable at:
> https://github.com/alexhayes/django-migration-fixture/pull/2/files.
>
> What is the suggested way to ha
Hey Warren,
this is a known problem in 1.7. It is fixed in 1.8
(see https://code.djangoproject.com/ticket/23745). Unfortunately, the
changes made to reduce the amount of get_models() and render() calls are
too invasive to backport them to 1.7.
If you have the time, could you try running your p
Hey Carsten,
Did you see the chapter at the end of the page you linked to: Upgrading from
South:
https://docs.djangoproject.com/en/1.7/topics/migrations/#upgrading-from-south
1. Make sure the database schema defined by your models (and Django migrations)
exactly matches the one in the database
Hey Anton,
You can find the release roadmap
at https://code.djangoproject.com/wiki/Version1.8Roadmap
The current plan is to issue the beta on Friday, given that all current
release blockers are fixed. There is a topic about the 1.8 release blockers
on the django-developers mailing
list: https
Hey Francis,
with respect to the ModelAdmin.readonly_fields: no, the vulnerability was
introduced in 1.7
with respect to the advisory: yes, all projects that make use the template
filters in Python code and rely on Django 1.0 to 1.8b1 (including) are
vulnerable.
Best,
/Markus
On Monday, Mar
Hi,
from the information you provided I can only guess you are migrating away from
a custom user model to the "normal" Django user model. This won't work (out of
the box). And even the way to migrate from the Django user model to a custom
user model is more of a workaround than a solution. Plea
Hey Wouter,
since Django 1.7 Model.check() is a reserved method that is used by the
system checks framework
(https://docs.djangoproject.com/en/1.7/topics/checks/#field-model-and-manager-checks).
The cleanest way is to remove that line (check = is_paid). Why do you have
that in the first place
Hey Jochen,
glad it works now. In that case you want to look at
https://docs.djangoproject.com/en/1.8/ref/settings/#migration-modules
and place the migrations somewhere in your project. Otherwise the
migrations end up in your virtualenv and are not available when you
deploy the application.
Best
Hi A Lee,
I think I've seen that one before. Can you check if the fix
for https://code.djangoproject.com/ticket/24573 resolves the issue?
/Markus
On Friday, April 17, 2015 at 2:52:26 AM UTC+2, A Lee wrote:
>
> Hello,
>
> After upgrading to 1.8 from 1.7.7 our tests are now unable to create test
Hi,
In principle it is possible to write your own or modify existing migrations
unless they are already applied.
Regarding the additional AddField() operations: in case you have e.g.
circular references between two models Django cannot add both models with
their full columns at the same time.
Hey Kaya,
I suspect you have South installed and in your INSTALLED_APPS. This is not
supported. South only supports Django <=1.6 -- Django >=1.7 has built-in
migration support. Please
see
https://docs.djangoproject.com/en/dev/topics/migrations/#upgrading-from-south
for a migration guide from
Hey there,
app labels (i.e. what you specify in your AppConfig or in AUTH_USER_MODEL)
are case sensitive. Thus either change AccountConfig.label to "account"
(this affects all migrations that depend on your account app) or
AUTH_USER_MODEL to "Account.User". I'd recommend to use lower case app
No need to apologize. If you think there is anything we can / should add to
Django's documentation that would have either helped you to figure out the
issue or that had prevented you from running into the issue in the first
place, please go ahead and open an issue at https://code.djangoproject.c
Which exact Django version did you use for generating and applying the
migrations? 1.7 as well as 1.8 had a few bugs regarding bytestrings.
They have been fixed in 1.7.something and 1.8.something. I'd need to
look up the exact patch version.
/Markus
On Fri, Jun 05, 2015 at 04:29:02AM -0700, Влад
Hey,
Not on djangoproject.com but you can use http://django.readthedocs.org/
/Markus
On June 12, 2015 8:32:09 PM GMT+02:00, "Davor Lučić" wrote:
>Hello,
>
>Is it possible to request documentation on docs.djangoproject.com
>without
>HTTPS?
>
>I work for corporation that either blocks or uses MIT
Hi Gergely,
You need to use apps.get_model() instead of get_user_model(). See
https://docs.djangoproject.com/en/1.8/topics/migrations/#data-migrations
/Markus
On June 17, 2015 12:48:48 PM GMT+02:00, Gergely Polonkai
wrote:
>Hello,
>
>I have created a new model called Settings, which has a
>O
Hey Anil,
On Sun, Sep 21, 2014 at 05:29:18PM -0700, Anil Jangity wrote:
$ python manage.py syncdb
Just as a side note: "syncdb" is deprecated and is being replaced by
"migrate".
I have a main/migration/update_site.py:
def update_site(apps, schema_editor):
current_site = Site.objects.get_
On Mon, Sep 22, 2014 at 08:41:36AM -0700, Anil Jangity wrote:
If I don't use syncdb, I should also create the super user account
using data migration? If so, it seems like I need to go do
User.objects.create_superuser().
There still is the option of running "python manage.py createsuperuser"
af
Hey Dan,
Without further details I tend to say no. However, the behavior is
different than the one you might be used to from South.
There is a ticket that can be used for discussions on that topic (for
now) [1].
/Markus
[1] https://code.djangoproject.com/ticket/23410
On Sun, Oct 05, 2014 at
Hey Torsten,
Are you talking about Django 1.7 migrations or South? In the former case
you need to make sure that your datamigration depends on the
contenttypes application.
If you use South: yes, calling update_all_contenttypes seems to be a
valid solution.
Best,
Markus
On Tue, Oct 21, 2014 a
Hey Michael,
The problem seems to be the same as in #23473
https://code.djangoproject.com/ticket/23473 . Try adding a __eq__ method on the
classes marked as deconstructible.
/Markus
On October 22, 2014 6:11:39 PM CEST, Michael
wrote:
>Hi,
>
>Does anybody know how are changes detected by the
Hey Hector,
There is a database table called "django_migrations" that is used to keep track
of the applied migrations. I guess it's not documented, because touching it
shouldn't ever be necessary.
It would be interesting to see how you ended up in a state that Django thinks
all migrations have
Hey Ed,
you certainly don't have to copy the virtualenv over to production!
Can you share some insights on your custom user model and your settings. A
complete traceback, if you have any, helps too.
/Markus
On Monday, November 10, 2014 9:00:04 AM UTC+1, Dr Ed wrote:
>
>
>
> On Sunday, 9 Novemb
Hey Hans,
As stated in the Docs
(https://docs.djangoproject.com/en/1.7/topics/migrations/#historical-models)
References to functions in field options such as upload_to and
limit_choices_to are serialized in migrations, so the functions will need
to be kept around for as long as there is a migr
Hey Nico,
if you want to dynamically determin the upload / storage path you should
use the "upload_to" parameter with a
callable:
https://docs.djangoproject.com/en/1.7/ref/models/fields/#django.db.models.FileField.upload_to
inside the callable you can safely access the settings without influe
Hey Nicola,
Django's migration system doesn't natively support "drop this foreign key
constraint from the database", because you shouldn't be able to run into
such a situation with the migration system at all (if you do, that's a bug
from my point of view). I suggest you go with a "RunSQL" oper
Hey all together,
unfortunately there isn't a way to add users through their manager in
RunPython yet. The only solution I can see so far, is doing it manually,
e.g. doing what your `create_user` method does inside RunPython. There is a
patch though #23822 [1] that needs some tests and docs, bu
Hey Oliver,
Can you try out the current 1.7 development branch. There is a fix [1] for
a recursion problem in the migration graph. Would be interesting if that
fixes your problem. Thanks.
[1]
https://github.com/django/django/commit/8e3c3be32d0c39a31997b905ebf0490280baa347
/Markus
On Saturday
Hi Tobias,
can you share the code for your old model and you new model along with the
existing migrations for that app, please. Without some details it's hard to
figure out what's happening.
/Markus
On Monday, December 8, 2014 8:23:33 AM UTC+1, Tobias Dacoir wrote:
>
> Hi,
>
> I'm having troub
A model is always uniquely identified by its app label and model name.
Since migrations use that I don't see a way how this could happen. If you
have two apps with the same app label the AppRegistry will blow up (and
prevents Django from starting).
On Monday, December 8, 2014 12:15:30 PM UTC+1,
I tried to reproduce the problem with the steps you explained, but it works
fine for me. Can you post your existing migration files for that app too,
please. This will then hopefully give us some hints to solve your problem.
On Monday, December 8, 2014 12:07:11 PM UTC+1, Tobias Dacoir wrote:
>
>
Hey Torsten,
It looks like you ran into the bug reported as
https://code.djangoproject.com/ticket/23956 . See my comment #6 for a
workaround.
/Markus
On Thursday, December 11, 2014 11:01:51 AM UTC+1, Torsten Bronger wrote:
>
> Hallöchen!
>
> Is it correct that when using multi-table inheritan
Hey folks,
Tim thankfully merged my patch and backported it to 1.7. You could check
out Django's stable/1.7.x branch to see if that solves your problem.
/Markus
On Thursday, December 11, 2014 2:21:41 PM UTC+1, Torsten Bronger wrote:
>
> Hallöchen!
>
> Markus Holtermann writes
Hey John-Scott,
I'm afraid but I don't see an obvious solution. There are 2 ways you could
work on the issue, I don't like either:
1. remove all references to the "foo_tag" app from all migration files
2. make use of the MIGRATION_MODULES settings:
2.1. create a package "path.to.foo_tag_legacy
the meantime, I'll settle for being able to get on with the rest of my life.
>
> On Tuesday, December 16, 2014 9:05:35 AM UTC-5, Markus Holtermann wrote:
>>
>> Hey John-Scott,
>>
>> I'm afraid but I don't see an obvious solution. There are 2 ways you
>
Hey,
Thank you for contributing. I would add the tests to somewhere in
"tests/validation/".
/Markus
P.S.: You might want to use the django-developers mailing list for
questions or discussion of the development of Django itself in the future.
On Sunday, December 21, 2014 3:13:55 AM UTC+1, Андр
Hey Bibhas,
thank you for the report. I can verify that behavior and would classify it
as a release blocker since it leads to potential data loss. Can you open a
ticket on https://code.djangoproject.com/ please.
In general a migration is a collection of operations. The migration will
only be u
Hey Alex,
a trailing . in the host header is valid per RFC 3986:
http://tools.ietf.org/html/rfc3986#section-3.2.2:
The rightmost domain label of a fully qualified domain name in DNS may be
> followed by a single "."
/Markus
On Monday, December 22, 2014 12:44:25 PM UTC+1, Alex Haylock wrote:
Hey,
I did indeed not consider the multi-threading behavior on uwsgi when
writing that. Can you post this to django-develop...@googlegroups.com
and open a ticket for that. I'd love to get someone else's input.
Thanks
/Markus
On Sat, Jul 09, 2016 at 08:36:44AM -0700, a.bra...@rataran.com wrote:
Thanks Andrea,
this is a known issue. Let me give you a bit of a history on this:
In 1.7 Django didn't do any caching. That was awfully slow for huge
projects like yours.
In 1.8 Django introduced heavy caching. Things improved speed wise but
failed horrifically when you were altering relations
Hi Dennis,
"indexes" is a new thing in the upcoming Django version. I'm fairly
certain that you accidentially used Django's development version at some
point while going through the tutorial.
Could you please paste your models.py and the migration files Django
created for you when you ran "manag
Hi Andrea,
If you have models that are entirely unrelated in different databases
you could use different values for INSTALLED_APPS to limit the apps
Django sees or by settings the values in the MIGRATION_MODULES dict to
None to tell Django that those apps don't have migrations.
Cheers,
/Markus
Hi, if the response you got is related to https://bitbounce.com/ , we're in
touch with them so that they can fix their system. Unfortunately, Google
Groups makes it really hard to find individual members and kick them, for
lists of the size of django-developers and django-users.
Cheers,
Markus
There's general interest in having support for composite keys and composite
foreign key. It's just that nobody has implemented it.
There are proposals among the DEPs that layout ideas how they could be
implemented:
- https://github.com/django/deps/blob/master/draft/0191-composite-fields.rst
-
Hey Kyle, that sounds about right. It's a variation of the "Migration Recipe" I
came up with a while ago:
https://markusholtermann.eu/2016/04/django-migrations-recipe-2/ . My question
would be if you really need the field of the new type to have the exact same
name as the old one. If you can li
I gave it a quick look, but I can't reproduce this issue on the current
master branch for SQLite3, PostgreSQL or MySQL. Can you give us more
information when you report the issue please, such as Django version,
database + version, database driver + version, and anything you think might
be helpf
Hi Graeme, the only solution that comes to mind is overriding the
alter_field() or _alter_field() methods on the schema
editor:
https://github.com/django/django/blob/stable/1.11.x/django/db/backends/base/schema.py
/Markus
On Wednesday, July 19, 2017 at 12:19:09 AM UTC+10, Graeme Perrow wrote:
Hey Joey,
not settings `auto_created=True` should do.
/Markus
On Thursday, August 6, 2015 at 1:17:09 PM UTC+10, JoeLinux wrote:
>
> Dear Anyone,
>
> I'm having an issue with a ManyToMany "through" table not being recognized
> by the makemigrations command. Please consider the model definitions
Hi Hollandz,
You can't do that from within Django automatically. You'd need to write
your own database migration to update the database as the assignment of the
primary key value is part of the database and not Django. Have a look
at
https://docs.djangoproject.com/en/1.8/ref/migration-operatio
On Mon, Aug 31, 2015 at 03:10:09AM -0700, Remaze Vs wrote:
view.py file
class DealsForm(ModelForm):
class Meta:
model = Product
fields =
['title','description','category','price','sale_price','slug','active','update_defaults','user']
exclude = ('user',)
model.py file
No, you can't because of two things:
1. SQLite doesn't allow an 'ALTER TABLE ... DROP COLUMN ...'
We get away with that by creating a new table and copying the data
over: https://www.sqlite.org/lang_altertable.html
2. SQLite doesn't allow a 'CREATE TABLE' statement without any columns:
Hello Iliana,
this is due to the definition of app_label = 'actstream' on your proxy
model. This tells Django that this model should belong to another app.
Hence the migrations involving that model are added to the actstream app's
migrations.
/Markus
On Friday, January 29, 2016 at 10:14:24 A
Thanks for the report Axel. This seems to be the same issue as the one
reported in https://code.djangoproject.com/ticket/29449 . A fix for this is
coming with the next pre release (beta 2 or RC1).
/Markus
On Wednesday, July 4, 2018 at 1:46:54 PM UTC+2, axel...@chaos1.de wrote:
>
> Hi,
>
> I tr
Hi Stefan,
You need to remove the parentheses `()` after `is_authenticated`.
Markus
On Thu, Oct 11, 2018, at 6:44 PM, Stefan Bethke wrote:
> First time poster here,
>
> I'm currently working on some unit tests of my Django app, and I'm
> running into a issue with is_authenticated.
>
> I'm usi
Hello all,
following a very long discussion on the django-developers[1] mailing list,
we've renamed the primary branch of the Django git repository from "master" to
"main".
Cheers,
Markus
[1] https://groups.google.com/g/django-developers/c/tctDuKUGosc/
--
You received this message because y
Hi all,
We took an defense-in-depth approach which seemed fined with our test suite.
But it turns out, there are cases that weren't covered by tests which caused a
regression in a few specific cases. This is tracked in
https://code.djangoproject.com/ticket/32718
Cheers,
Markus
On Fri, May 7,
Hi Mike,
Last time I checked, when you set `instance.pk = None` and then do
`instance.save()`, Django will create a new instance.
Cheers
Markus
On Mon, Jul 26, 2021, at 9:13 AM, Mike Dewhirst wrote:
> I'm archiving a particular child record every time it is saved but
> connecting it to anothe
Hi Daniele,
wow, these are wonderful news! Thank you for all your time on psycopg2 and now
3!
>From where I'm standing, I agree, having the psycopg3 Django backend as an
>external package for now sounds good. It's much easier to keep updated and
>maintained, without having to go through all of
Yes, I do see several problems. Some of them:
- All middleware are run for every request
- What you're doing can slow down your request response time to minutes,
depending on home many migrations you have
- Depending on your database, migrations might not be atomic thus causing
conflicts
- You h
62 matches
Mail list logo
