jerch

There is a possible incongruency in fast_update (and copy_update), if the method gets called on a prefiltered queryset: - local field update path ignores any prefiltering - nonlocal field updates...

Big chance - 4.2 brings psycopg 3 support, which makes things alot easier and alot faster in the `copy_update` path. Downside - a partial reimplementation is needed to get things...

needs a better pk duplicate handling

1

With #12 we introduced set based pk duplicate detection in python, which is not how it should be done. We simply cannot do that solely in python, as the db...

Is upsert worth to be implemented in an optimized fashion? (either fast or copy path, or both?)

GIS fields are currently not supported by `copy_update`.

idea - should the postgres copy path get a copy_insert/create method?

20

There is a possibility for a much faster `copy_create` alternative to `bulk_create`. From some initial tests that would be 10-20 times faster than the current implementation, but will have several...

Some optimizations

4

Here are some quick optimizations to speedup the code in CPython. Most bottlenecks are cascades of function calls, esp. the setter/getter of the register objects (commit 9b73477da6612985f0713a4617b53ee47ee1bc00, fac8dbca90a5d5e716be49f5ee60c509620703fd and partly...

Currently the tree update view actions are hardcoded to `@login_required`, which might be unwanted in certain cases. This needs some thinking, how to make this customizable from the default permissions...

handle actions by fk related manager

1

Currently many actions of related managers are not properly handled - some work, others dont. Seems the reason for some not working comes from bulk usage internally (all have a...

minor optimization possible with .only?

1

In theory we know all local fields, that are needed to update a cf, thus could lower the db/ORM/memory stress by only loading those fields with `.only`. Needs some investigation,...