Fellow Reports - February 2023
Week ending February 5, 2023 Released Django 4.1.6, 4.0.9, and 3.2.17. *Triaged:* https://code.djangoproject.com/ticket/34301 - "show_save_as_new" in admin can add without this permission (accepted) https://code.djangoproject.com/ticket/34304 - Adding and removing a conditional UniqueConstraint to ForeignKey multiple times crashes on MySQL (accepted) https://code.djangoproject.com/ticket/34307 - Issue with min_num logic in InlineFormsets (needsinfo) https://code.djangoproject.com/ticket/16180 - IGNORED_PARAMS customization (wontfix) https://code.djangoproject.com/ticket/34308 - Create Serializers for models (wontfix) https://code.djangoproject.com/ticket/34310 - Add deletion example at one_to_one relations documentation (accepted) *Reviewed/committed:* https://github.com/django/django/pull/16499 - Fixed #34283 -- Escaped title in admin's changelist filters. https://github.com/django/django/pull/16510 - Fixed #34180 -- Added note about resetting language in test tear-downs. https://github.com/django/django/pull/16509 - Fixed #34304 -- Made MySQL's SchemaEditor.remove_constraint() don't create foreign key index when unique constraint is ignored. https://github.com/django/django/pull/16516 - Refs #33476 -- Applied Black's 2023 stable style. https://github.com/django/django/pull/16517 - Fixed #34286 -- Fixed admindocs markups for case-sensitive template/view names. https://github.com/django/django/pull/16454 - Fixed #34259 -- Passed called_from_command_line to command subparsers. *Authored:* https://github.com/django/django/pull/16518 - Improved error message for ASCIIUsernameValidator. https://github.com/django/django/pull/16521 - [4.2.x] Increased the default PBKDF2 iterations for Django 4.2. https://github.com/django/django/pull/16522 - Increased the default PBKDF2 iterations for Django 5.0. Best, Mariusz -- 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/2132a970-e857-04ae-c2f1-6080c15b8a11%40gmail.com.
create database view from another table
I had a problem and solved it; just want to know if there was another more elegant solution than the one I did. Please let me know if you know of a better option: The issue: have a date-time column in my specific SQLITE3 table. wanted to create Year, Month, Day, Hour, Minute, Seconds and a few others like DATE and TIME. Not practical to clone the database table, so wanted a 'View' against it. 2) went to my project folder and brought up the MODELS.py, and cloned the table, and added a *project_Vtablename* table. (added the "V" in front of the table's name. 3) Went thru the "*makemigrations*" option, then the "*migrate*" option. when it successfully finished, I had both the* project_tablename* and *project_Vtablename* tables in the DB. 4) then to insert the extra columns, went to SQLITE3, developed and debugged a *CREATE VIEW **project_Vtablename* statement, with all the additional columns added (Year, Month, etc). Of course I deleted the *project_Vtablename *before creating it as a VIEW. 5) returned to the VIEWS.py program and copied the IMPORT statement to add the *project_Vtablename* , and cloned a function that is successfully reading the original - changed all instances of tablename to Vtablename. AND it WORKS. Now, with the *Year *column, i can now much more easily use and understand my SQL filters when parsing a date-time column. ...so, is there a *more elegant way* to install a database VIEW than a method something like the above? If so, please SHARE IT so I and others can take advantage of it. -- 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/e6625891-03f8-4724-b23d-a4e42e0150b3n%40googlegroups.com.
Re: create database view from another table
Hi Mike, this is not really the correct list for your question - this list is about development _of_ Django, not _with_ Django. That said: did you consider adding an index for each of the derived values you wanted? This can act as an efficient way to keep, effectively, a "cache" of values derived from commonly used expressions. The downside is your queries MUST use the same expression in order for the index to be considered. The practice of wrapping a VIEW in an unmanaged Django Model (i.e. Meta.managed = False) is a long established and well tested pattern, though your approach to achieving this is novel. Personally, I would: - get the SQL Django emits to create the original table using "sqlmigrate" - alter it to a CREATE VIEW with the additional fields, etc - clone the Model class definition, add new fields, and set Meta.managed = False, and Meta.db_table to the view name. - run "makemigrations" - Add a raw SQL migration using the CREATE VIEW statement. - run "migrate" On Tue, 7 Feb 2023, at 07:48, Fred Mayer wrote: > I had a problem and solved it; just want to know if there was another more > elegant solution than the one I did. Please let me know if you know of a > better option: > > The issue: have a date-time column in my specific SQLITE3 table. wanted to > create Year, Month, Day, Hour, Minute, Seconds and a few others like DATE and > TIME. Not practical to clone the database table, so wanted a 'View' against > it. > > 2) went to my project folder and brought up the MODELS.py, and cloned the > table, and added a *project_Vtablename* table. (added the "V" in front of > the table's name. > > 3) Went thru the "*makemigrations*" option, then the "*migrate*" option. > when it successfully finished, I had both the* project_tablename* and > *project_Vtablename* tables in the DB. > > 4) then to insert the extra columns, went to SQLITE3, developed and debugged > a *CREATE VIEW **project_Vtablename* statement, with all the additional > columns added (Year, Month, etc). Of course I deleted the > *project_Vtablename *before creating it as a VIEW. > > 5) returned to the VIEWS.py program and copied the IMPORT statement to add > the *project_Vtablename* , and cloned a function that is successfully > reading the original - changed all instances of tablename to Vtablename. AND > it WORKS. > > Now, with the *Year *column, i can now much more easily use and understand my > SQL filters when parsing a date-time column. > > ...so, is there a _more elegant way_ to install a database VIEW than a method > something like the above? If so, please SHARE IT so I and others can take > advantage of it. > -- Curtis -- 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/d23bd268-bbb0-410a-b067-6f771332734b%40app.fastmail.com.
