jerch
jerch
Django 5.2 introduced composite pks, which are not yet supported.
If COPY FROM runs threaded and raises, the exception gets swallowed and the caller thread happily finishs. On a sidenote - looks like the custom threading is not needed anymore...
#25 introduced _merged_update_, which tries to find a clever update strategy by merging field values. Both - the merge and the prediction, need better algos and test cases to leave...
There are some code smells in the management commands: - using print instead of `self.stdout.write` - `sys.exit` calls - prolly others smells
Django 5.2 introduced composite pks, which are currently not supported.
#196 revealed several performance smells, that shall be covered here: - [x] runtime caches - [x] discourage _bulk_update_ - [x] new update impls: _merge_update_ & _flat_update_ - [x] integrate new...
While the resolver already holds most dependency graph aspects in flat data structures for fast access, we still have a few methods, that have to calculate their final values based...
This is just a playground for now... The limitations around UNIONed queries and the .only idea made me think, whether we can safe update runtime by further cutting ORM ropes....
We need some clarification regarding computed fk fields: - To what degree can they be used in _depends_? - Is there an easy way to fully support them in _depends_...
Coming from #168: There is a bug hidden in the field deps resolving for `related_name_query`, where an empty field list on the right side will not uncover all needed deps,...