addListDetails was not optimized to build unique list of list owners #1189
No reviewers
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#1189
Loading…
Reference in New Issue
No description provided.
Delete Branch "k2s/api:k2s-addListDetails-too-many"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
solves one of multiple problems related to #1188
This is a bit more complicated.
MySQL and Microsoft Sql server (I think?) will optimize huge
where in()
queries with duplicate values. Postgres or SQLite won't do that and SQLite has an upper limit of how much values it can handle (as you probably already discovered).I've asked about this on Stackoverflow: https://stackoverflow.com/q/62392660/10924593
For postgres it seems like it can handle these huge lists of values without provlems so it won't bother to optimize them.
Now because there's a lot of cases where we're using these kinds of queries this should ideally go into the orm. In fact, I started a PR some time ago do o just that: https://gitea.com/xorm/builder/pulls/76
I think we should continue that one instead of manually adding the cleanup everywhere in Vikunja. Maybe it'd worth it to modify that PR so that it would only optimize for SQLite since this only seems to be a problem with SQLite and not other DMBS.
The PR in xorm was merged, I think we can close this now.
Pull request closed