Re: Support of django 3.2

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

Re: migrations not created for foreign key when primary key type is changed

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

Re: Django backend for Psycopg 3

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

Re: Is there a quick and easy way to copy a model instance

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

Re: [django-announce] Django security releases issued: 3.2.1, 3.1.9 and 2.2.21

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

Primary Git branch renamed

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

Re: Running pending migrations in Middleware

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

Re: Zero Downtime Field Type Changes

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

Re: Re: Composite Primary / Foreign Key support

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 -

Re: SPAM sent via this list?

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,

Re: AnonymousUser.is_authenticated woes

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

Re: 2.1b1: Getting "unexpected keyword argument 'limit_choices_to'"

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

Re: Migration for auth_user.username field

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:

Re: sqlmigrate does not quote default string values

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

Re: Migrations with multiple databases

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

Re: TypeError: 'class Meta' got invalid attribute(s): indexes

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

Re: Django migrations taking all the memory on Django 1.9

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

Re: Possible Bug in RegexURLResolver

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

Re: proxy model inheritance generates a migration file in a third party app

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

Re: Can you remove a model's last field of SQLite3 in Django 1.8?

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:

Re: I have error like Type Error save() takes at least 2 arguments (1 given) in Django project.

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

Re: About the auto-increase PK

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

Re: auto_created getting ignored by makemigrations

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

Re: ValueError during migrations.RunPython to create OneToOne records in new model

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

Re: HTTPS on docs.djangoproject.com

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

Re: Bug in 1.7-1.8 migrations

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,

Re: Little trouble with migration.

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

Re: Little trouble with migration.

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

Re: “Migrate” command for manage.py not recognised when using Django 1.8

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

Re: Slowness of the resulting squashed migration

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.

Re: Django 1.8 data migrations not able to locate related collections

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

Re: django 1.8 upgrade custom user model syncdb

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.

Re: Django system check gives error when storing method in variable

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

Re: migrations don't work

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.

Re: [ANNOUNCE] Security releases and advisory issued (1.7.6 and 1.8b2)

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,

Re: Release announcements?

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:

Re: Migrating to initial migration: "ORA-00955: name is already used by an existing object"

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

Re: Slow test startup under Django 1.7

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

Re: Data migration fails because contenttypes not yet ready

s mentioned above is viewable at: > https://github.com/alexhayes/django-migration-fixture/pull/2/files. > > What is the suggested way to have initial data with Django 1.7, given that > initial_data is not used for apps with migrations, and RunPython has the > above shortcomings? > > &

Re: do migrations (Django 1.7+) handle production data?

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

Re: malicious requests?

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

Re: How to make a migration irreversible [1.7]

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

Re: Where to put my bugfix tests?

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,

Re: Django 1.7: How to migrate data between two external apps

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 >> could work on the issue, I don't like either:

Re: Django 1.7: How to migrate data between two external apps

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

Re: Multi-table inheritance and primary keys

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: &g

Re: Multi-table inheritance and primary keys

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

Re: Changes to Model does not migrate to sqlite with Django 1.7?

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: >

Re: Changes to Model does not migrate to sqlite with Django 1.7?

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

Re: Changes to Model does not migrate to sqlite with Django 1.7?

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

Re: Generated migration blocks my application

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

Re: Using data migration to create initial users errors

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,

Re: django 1.7 migrations upgrade from south: db.delete_foreign_key replacement?

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"

Re: Migrations and FileField storage

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

Re: 1.7 migrations: problem with renamed upload_to function on FileField

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

Re: Where does django store auth migrations?

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

Re: re-apply migrations on restored database

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

Re: django 1.7 migrations: changes detected while nothing has changed ?

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

Re: Data migration fails because contenttypes not yet ready

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

Re: Backwards migrations on a single app (Django 1.7)

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

Re: updating site domain with data migration

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"

Re: updating site domain with data migration

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 =