Query on nested id field incorrectly returns no results [DATAMONGO-2193]

[spring-projects-issues]

Joseph Blair opened DATAMONGO-2193 and commented

I have a field id in a nested object, which serves as a reference to other Mongo objects, so it is generally a Mongo-style ObjectId represented as a string.  It is declared as follows:

@Field("id")
private String id;

 

Upon upgrading from Spring Data MongoDB 1.10.5 to 2.1.1 for compatibility with Server 3.6, queries on this field now erroneously return no results.  I suspect what's happening is that the query should be executed as follows (this is what is returned by query.toString()):

db.myCollection.find({"group.id": "5acf..."})

But instead, it's being executed as:

db.myCollection.find({"group.id": ObjectId("5acf...")})

That suspicion seems to be confirmed by the fact that changing an existing document, directly in the database, from "id": "5acf..." to "id": ObjectId("5acf...") causes it to be returned by the query.

It looks like this might be the same bug described by DATAMONGO-1798.  I wanted to confirm if that's the case, and see if there is some other alternative solution since I assume 2.2 won't see general release for at least a few months.  It was working as expected prior to the version upgrade, so we're really just looking for a way to restore the previous behavior.

 

---

Affects: 2.1.4 (Lovelace SR4)

Issue Links:

• DATAMONGO-2205 Searching by nested object with ID doesn't return any result

Referenced from: pull request #640

Backported to: 2.1.5 (Lovelace SR5)

[spring-projects-issues]

Christoph Strobl commented

Thanks for reporting. I fine tuned the id detection in the QueryMapper a bit so that it does not recognize

@Field("id")
String id;

as an id property.

Build snapshots (2.1.x.DATAMONGO-2193-SNAPSHOT) available via repo.spring.io .

[spring-projects-issues]

Joseph Blair commented

Christoph Strobl Perhaps I'm doing this wrong, but I added a POM dependency like so and it says it can't be found: 

<dependency>
    <groupId>org.springframework.data</groupId>
    <artifactId>spring-data-mongodb</artifactId>
    <version>2.1.1.DATAMONGO-2193-SNAPSHOT</version>
</dependency>

 

I also don't find any reference to the package in either of these locations in the UI:

https://repo.spring.io/webapp/#/artifacts/browse/tree/General/libs-milestone-s3-cache/org/springframework/data/spring-data-mongodb/1.0.0.M1/spring-data-mongodb-1.0.0.M1-sources.jar

https://repo.spring.io/webapp/#/search/quick/eyJzZWFyY2giOiJxdWljayIsInF1ZXJ5IjoiREFUQU1PTkdPLTIxOTMtU05BUFNIT1QifQ==

[spring-projects-issues]

Joseph Blair commented

I looked at the PR, and thought maybe my POM dependency should be declared like this instead, but same result:

 

<dependency>
<groupId>org.springframework.data</groupId>
<artifactId>spring-data-mongodb-parent</artifactId>
<version>2.1.x.DATAMONGO-2193-SNAPSHOT</version>
</dependency>

 

[spring-projects-issues]

Oliver Drotbohm commented

The artifacts are available via spring-data-mongodb in version 2.1.x.DATAMONGO-2193-SNAPSHOT

[spring-projects-issues]

Joseph Blair commented

Got it, had to define the repository as:

<repository>
   <id>spring</id>
   <url>https://repo.spring.io/libs-snapshot</url>
</repository>

I haven't done an exhaustive test, but it seems to fix the bug from the original use case.  I checked for regressions on a few similar use cases that were working previously, and they seemed to work as expected also.  Do you have any idea which version/s this would be merged into, and what the timeline for general release might look like?

 

[spring-projects-issues]

Christoph Strobl commented

The fix should go into Lovelace SR5 (expected mid Feb.) and the next milestone of Moore. 

[spring-projects-issues]

Joseph Blair commented

Christoph Strobl Thanks for the update.  Do you know in which version the original change might have been introduced, so I can roll back until 2.1.5 is released?

[spring-projects-issues]

Joseph Blair commented

2.1.5 appears to have fixed the original case I flagged here, but the same bug is still occurring in a different case.  I'm not sure why the two cases are behaving differently.  My only guess is that this new one is a doubly nested field (eg, trigger.assignee.id) instead of singly nested (eg, recipient.id).  Let me know if I can provide any other useful information.  Thanks