Any issue filtering documents using gte and lte (Ranges) ?

[mpellicer]

Hello,

I found something weird when writing unit tests and using the embed mongo instance, for some reason, a simple query using gte and lte does not work, does not return any object. I'd like to filter documents by budget setting a min and a max value.

I wrote a Kotlin snippet showing this behavior, first I get all the items, then filter the object, you can see the items listed in the console.

After that, I use a repository method to do the same, it does work in a real MongoDB instance.

Debugging the queries, they look correct, but return 0 items.

Pasting the same query into a real MongoDB instance it works fine.

Do you think there could be an issue filtering items by double value?

Thank you very much for any help and congratulations for such an amazing library.

[michaelmosmann]

@mpellicer .. which mongodb version do you use for test and for production? (the real mongodb instance)? If you set an breakpoint in your test code you can connect to the mongodb instance used in this test to execute the query and see if it also works there..

[mpellicer]

Hi @michaelmosmann, the test library is running 7.1.0 while production is 7.0.6.

de.flapdoodle.mongodb.embedded.version=7.1.0

I tested multiple combinations but none of them work for me, I know it's very obvious and simple, but I can't get any items using the lte and gte filters :(

Thanks for your response! It does not urge to me since the logic is working fine with the real mongo DB.

[michaelmosmann]

@mpellicer . so your code works in prod but not in test? Is there any way to isolate your setup into a mini project? Maybe choose one of the matching sub module from that project: https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo.canary ..

[mpellicer]

Correct, works fine with a real MongoDB but not with the embedded, despite it shows the same SQL, the results are different, the embedded DB returns 0 documents.

{"budget", {"$gte": 0.0, "$lte": 1000.0}}

Let me try to reproduce it forking the repo, thanks again

[michaelmosmann]

@mpellicer .. hmm.. interesting.. maybe it some index stuff.. this is kind of strange..

[mpellicer]

@michaelmosmann There u go.

I uploaded the changes into this branch:

https://github.com/mpellicer/de.flapdoodle.embed.mongo.canary/tree/rangebug

Here is the simple commit:

https://github.com/flapdoodle-oss/de.flapdoodle.embed.mongo.canary/commit/987dab9f07f05f3650175a763ad8e630ebc8268b

What do you think ?

[michaelmosmann]

@mpellicer awesome.. i will have a look into that later in the evening..

[mpellicer]

@mpellicer awesome.. i will have a look into that later in the evening..

No hurries, thanks for everything

[michaelmosmann]

@mpellicer .. using BigDecimal instead of Double will map the budget attribute to String instead of Number (Decimal128 Bson Type), so that the query not match at all.. if i change the type from BigDecimal to Double your tests are working.

see https://docs.spring.io/spring-data/mongodb/docs/current-SNAPSHOT/reference/html/#mapping-conversion

[mpellicer]

Thanks @michaelmosmann , there's definitely something wrong around filtering with BigDecimals and JPA.... I'll keep investigating!

The real MongoDB does not filter values using a query like this: { "budget" : { "$gte" : "1000", "$lte" : "4000"}} But the embedded library does, same when using doubles, the real works but the embedded not, weird!

We can close this issue if you want and thank you very much for looking into it!

[michaelmosmann]

@mpellicer .. i will add some tests on your branch .. maybe this will help you with this kind of problem..

[michaelmosmann]

@mpellicer did a pull request: https://github.com/mpellicer/de.flapdoodle.embed.mongo.canary/pull/1

[mpellicer]

Thanks @michaelmosmann ! I think it makes sense to use Double instead of BigDecimal here, as you said before, JPA maps BigInts as Strings, making the query not working. Thanks for the PR and the clarification, I feel sorry and I hope this is helpful for somebody in the future.

[michaelmosmann]

@mpellicer .. don't feel sorry for that.. in the end we both learned something new, and that's not a bad thing:) ... and maybe this will help others.. that's a bonus:)