database column order
hello there, an interesting topic popped up on HN: Column order in PostgreSQL does matter https://news.ycombinator.com/item?id=32067473 I was wondering how django does this, so I looked at some of the sql generated by migrations in my apps (particularly initial ones) and if I read the SQL correctly django mostly matches column order with the model fields order with the notable exception of foreign key(s). Those being (by default and quite often) fixed width, and it seems that they might benefit from the order described in the articles, I was wondering what was the reason for putting them at the end. -f -- -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/Ys3JwwWAJ3BtX/qo%40obiit.org.
Re: database column order
charettes - Tue, 12 July 2022 at 13:11:14 > If you add fields to one your existing models the migration framework will > add them at the end of your table as that's the most straightforward way of > doing so. Of the top of my head only MySQL supports a syntax to add a is it a correct takeaway, that while building an app and playing with model fields left and right, before going live it's a good practice to remove all migration files and let django recreate them and the DB? in my understanding that will recreate the tables with a column order closer to model fields order (plus reduce the number of migration files), while flattening the migrations probably keeps the previous order? > models that have a different field layout than their table. The migration > framework also doesn't have any notion of field ordering right now so that > would also be work that needs to be done. i think the current situation is a kind of sweet spot where there is room for a bit of manual "optimisation" by ordering the fields. going web-scale will need more consideration by those lucky ones :} > I'm of opinion that if you are experiencing performance issues due to the > physical layout of a particular table managed by Django you're likely > better off not relying on the automatically generated migrations that > Django provides and use a mix of `RunSQL` and `SeparateDatabaseAndState` to > achieve what you're after. i think it's more about wasted disk space than raw performance (although one is related to the other). thank you for the indepth answer. -- -f -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/Ys7ArlS5VttSFSA9%40obiit.org.
POSTs that are not form data and technical_500.txt
Hello, fishing for some ideas here. consider this scenario: ``` ... Subject: [Django] ERROR (EXTERNAL IP): Internal Server Error: /c/add/ ... Internal Server Error: /c/add/ UnboundLocalError at /c/add/ local variable 'model' referenced before assignment ... Traceback (most recent call last): ... Exception Type: UnboundLocalError at /c/add/ Exception Value: local variable 'model' referenced before assignment Request information: USER: AnonymousUser GET: No GET data POST: No POST data FILES: No FILES data ... ``` i love technical_500.txt. my collegues are continually amazed how i knew they ran into an issue a minute ago and simple fixes are pushed immediately with no other triaging involved. but in this case it's borderline useless. what happened? request.POST vs request.data happened. i am not advocating putting optional package info into technical_500 of course (request.data is a drf construct iirc). but would it be feasable to show (a part of) request.body if method is POST and Content-Type is application/json (perhaps xml could be handled similarly)? ps. why not a custom middleware? i think this is a battery that would be nice :} -f -- -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/Y0Wbj8ATRN2PCjhK%40obiit.org.
Seamless Application Failover using libpq
hello, i was wondering if there was any work done/planned/discussed about implementing support for this really useful feature of libpq: $ psql 'postgres://host1:5432,host2:5432,host3:5432/postgres?target_session_attrs=read-write' Psycopg claims to support all dsn parameters. https://paquier.xyz/postgresql-2/postgres-10-libpq-read-write/ https://www.postgresql.org/docs/12/libpq-connect.html target_session_attrs If this parameter is set to read-write, only a connection in which read-write transactions are accepted by default is considered acceptable. The query SHOW transaction_read_only will be sent upon any successful connection; if it returns on, the connection will be closed. If multiple hosts were specified in the connection string, any remaining servers will be tried just as if the connection attempt had failed. The default value of this parameter, any, regards all connections as acceptable. this has the potential of making failover possible without any additional software. a quick search through the tickets and PRs brought up no results. -f -- -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200424085821.GA87143%40obiit.org.
Re: Reverting Django 3.1. to Django 3.0.6 raises "binascii.Error: Incorrect padding".
Adam Johnson - Fri, 15 May 2020 at 17:53:21 > At least two of the major database servers that Django supports, PostgreSQL > and MySQL, provide zero downgrade-ability. It's too hard for them to do. while this is now officially true for both MariaDB and MySQL, until recentlyish it was possible to downgrade them after carefully reading changelogs. This is now unsupported and even runtime errors are generated. AFAIK postgresql is/was always safe to upgrade/downgrade if staying on the same major version. having said that i think downgradability requires massive engineering resources for very little return in case of a project like django. long story short: never upgrade without reading changelogs, running the testsuites, and deploying on test/staging first. It's not simply a matter of bumping a number in requirements.txt, although it has happened many times that no other changes were required :} -f -- -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/20200515231835.GB3895%40obiit.org.
Re: Proposal: django project name
Christian González - Wed, 13 May 2020 at 22:13:34 > TL;DR: Django has no (builtin/explicit) settings variable like > PROJECT_NAME. Should have. 4 of those were comments (i wish the project templates stopped doing that) 3 of those were env variables which a deployment can override with an actual environment variable anyway... introducing variables/constants into the settings/etc can help but sometimes it also makes it more rigid and cluttered. it's a balancing act that has a different sweet spot for everyone. but there is nothing stopping you from using one. i do. some other potential uses: - logging setup - ADMINS - FORMAT_MODULE_PATH -f -- -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/2020051525.GC3895%40obiit.org.
