-
-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Cast datetime columns in sqlite before comparing #26540
Conversation
Looking at https://github.com/nextcloud/server/blob/master/lib/private/DB/QueryBuilder/ExpressionBuilder/OCIExpressionBuilder.php thats a lot of duplication. Xan we abstract the prepareColumn calls to another level? |
cfc381e
to
f2d744b
Compare
@nickvergessen I moved the prepareColum to the regular ExpressionBuilder so that sqlite and OCI now just extend that. |
f2d744b
to
43608b8
Compare
Can we add a test? :) |
Definitely. I'd probably add a case for this in https://github.com/nextcloud/server/blob/6312c0df6949955d1cd59c3dd444268e0773293c/tests/lib/DB/QueryBuilder/ExpressionBuilderDBTest.php but we'd need a new table in the testing app to properly test this against real databases. Or would you have any other idea to cover that? |
43608b8
to
ab3cdcc
Compare
Rebased and pushed a test case for this. I added a new table to the testing app to have a datetime column around during tests. |
197d052
to
c829472
Compare
c829472
to
4d1edf2
Compare
4d1edf2
to
58c4c1e
Compare
Move the logic to prepare a column to the parent ExpressionBuilder so that it can be reused for OCI and sqlite Signed-off-by: Julius Härtl <jus@bitgrid.net>
Signed-off-by: Julius Härtl <jus@bitgrid.net>
58c4c1e
to
e50cb0a
Compare
When debugging failing integration tests in nextcloud/deck#2934 i noticed that sqlite does strange things when trying to compare a datetime field with a DateTime value through the expression builder. It turns out sqlite doesn't store them as real dates and therefore operates a string comparison through our database abstraction:
https://www.sqlite.org/datatype3.html
In order to resolve this issue globally this PR wraps the required parameters when they are passed to the query builder with using the
DATETIME()
function so both values are compared as real datetimes.Might make sense to also look into covering this with some tests, but I didn't have time to look into yet. I can have a look if the general approach to this is fine.