-
Notifications
You must be signed in to change notification settings - Fork 11
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
Upgrading to 1.0.0-dev.83 cause previously working queries to fail #7
Comments
+1 |
All my where queries return no result |
Yep. I replaced all the queries with direct queries. The only dependency I
have is now on model objects.
…On Wed, Feb 21, 2024 at 4:56 PM Dor Klein ***@***.***> wrote:
All my where queries return no result
—
Reply to this email directly, view it on GitHub
<#7 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAQ4MLQBIPSUUMFNXPG7YH3YUXKXFAVCNFSM6AAAAABDCV466OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJWGQ2DKMJUGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Same here. All get queries using any kind of final configs = await configurationRef
.whereCreatedBy(isEqualTo: userId)
.wherePartNumber(isEqualTo: partNumber)
.whereDeleted(isEqualTo: false)
.get(); Switching to direct queries works |
@rrousselGit This looks to be a pretty nasty bug. Do you have some free time to take a look? It might be related to the recent |
I can confirm this behavior. In my case the generated query with where clause is containing duplicated query fields with each a valid value and a null value using the AND operator. This is not limited to only to isEqual. Duplicated query fields with null in bold below.
@rrousselGit My best guess is the _WhereMapper is doing double duty with broken logic. |
I have created a sample project you can use to reproduce this, if that helps. https://github.com/urbanmania/test_project If you run it as is you will get the error. If you comment out this line the error is gone (but also the access control) https://github.com/urbanmania/test_project/blob/0931902c0feb202212a792f9cffe33d74363cd85/lib/main_list_view.dart#L15 It is not the first time I've seen this error, previously it broke and then magically got fixed but broke again with the latest update. |
It appears no maintainer is actively watching this project anymore since the transfer ... To me it looks like an abandoned project. |
It isn't abandoned by any means. It's not receiving any more or less updates than before. There's no real bug here. It's because your ODM version is higher than your Firestore version. You use firestore <4.15.0, but the latest ODM. I'll bump the minimum Firestore version necessary to fix – and fix a bug specific to arrayContains. But otherwise, it's working well. |
@rrousselGit my ODM version is not higher than my firestore version; as written in the initial issue, I produce the bug with cloud_firestore version 4.15.4. I tested again with: The bug is still there. |
You're right, there is a separate issue specifically with how the ODM passes |
I confirm it's fixed, thank you @rrousselGit. As a side note, I don't know if it's intended but there is a discrepancy of version between cloud_firestore_odm which stayed 1.0.0-dev.84 while cloud_firestore_odm_generator have been pushed to 1.0.0-dev.85. |
Confirming this issue is fixed ! Thx @rrousselGit ! |
Not quite sure why, but this isn't fixed for us. Some sample code: SomeCollectionReference(firestore)
.whereFieldPath(FieldPath(const ["creator"]), isEqualTo: uid)
.snapshots()
SomeCollectionReference(firestore)
.whereCreator(isEqualTo: uid)
.snapshots() Both of these stopped working, |
@ciriousjoker dev version 84 of generator is flawed, you have to use the 85. In my
After upgrading and |
@gmarizy ah yes thanks! Forgot to regenerate the files after updating. Now it's working! |
Expected Behavior
Same behavior between 1.0.0-dev.82 and 1.0.0-dev.83
Actual Behavior
Some requests fail with error like "You cannot use '!=' filters more than once", even in request where there is only isEqualTo where clauses, after updating to 1.0.0-dev.83.
Steps to Reproduce the Problem
Specifications
The text was updated successfully, but these errors were encountered: