Will there *not* be a Django ORM implementation of psycopg3 COPY FROM
when that lands? And, I guess I'll need to figure out when that
lands/would land.
Not automagically, since the ORM does not use COPY internally. The main
ORM parts are pretty generic, thus mostly based on ANSI compliant SQL
Will there *not* be a Django ORM implementation of psycopg3 COPY FROM when
that lands? And, I guess I'll need to figure out when that lands/would land.
On Tuesday, October 18, 2022 at 11:07:51 AM UTC-4 j.bre...@netzkolchose.de
wrote:
> > pretty quickly, so if you need testing input (Django
> pretty quickly, so if you need testing input (Django 3.2, Postgres) I
> can offer feedback from what I find.
Yes testing would be awesome, esp. for edge cases (test coverage for
default cases is pretty complete for `fast_update` I think).
> Can you tell me more about this statement:
> >
Jerch,
I love that you're improving the `bulk_update` performance with your
package. I am definitely looking to adopt it. I can start working on it
pretty quickly, so if you need testing input (Django 3.2, Postgres) I can
offer feedback from what I find.
Can you tell me more about this
Released the second version of fast_update
(https://pypi.org/project/django-fast-update/), based on some findings
above, e.g. it now should work with all recent db engine versions
supported by django (despite oracle).
Would be happy to get some tests/feedback, before moving things closer
to
Have found workarounds for older db engines, which makes the more
demanding version requirements from above obsolete. Db support with
these workaround would be:
- SQLite 3.15+ (should work with Python 3.7+ installer, Ubuntu 18 LTS)
- MySQL 5.7+ (older versions should work too, not tested)
The
Some findings/ideas on possible expression field support:
The SQL standard requires, that within a single UPDATE command the
column ordering does not matter. This effectively means, that the RHS of
the SET clause operates on old record values, while LHS gets the new
values, which dont
@Mariusz
Thx for the update on the db support roadmap, helps alot to get things
into perspective.
@expression support
After a few more tests it turns out, that expression support prolly can
be saved exactly as it is by a combination of the current CASE chaining
with the VALUES table. At
Support for MariaDB 10.2 is already dropped in Django 4.1. We will drop
support for MySQL 5.7 in Django 4.2 or 5.0 (probably 4.2).
See https://code.djangoproject.com/wiki/SupportedDatabaseVersions for more
details.
Best,
Mariusz
--
You received this message because you are subscribed to the
@Florian
Thx for your response.
Looking through the release notes and the listed databases I find these
version requirements:
- PostgreSQL 10+
- MariaDB 10.2+
- MySQL 5.7+
- Oracle 19c+
- SQLite 3.9.0+
Compared to the UPDATE FROM VALUES pattern requirements:
- MariaDB 10.3.3+
- MySQL 8.0.19+
Hi Jörg,
Regarding your question about database version support:
https://docs.djangoproject.com/en/4.0/ref/databases/ lists the supported
versions. Granted not as support grid and you have to scroll to every
database, but it is usually in the first paragraph.
If f-expressions are currently
11 matches
Mail list logo
