Did querying for @References stop working in 0.106-SNAPSHOT ?

[Patricio Echague]

After moving my project to 105 and 106-SNAPSHOT respectively several of our regression tests stopped working.

The query returns nothing or in my case the count() returns 0;

Example:

class Org {

    @Reference(FIELD_PLAN) private Plan plan;

}

In my DAO

public long countAll(List<Plan> plans, Boolean hasRecurlyAccount) {

Query<Organization> q = createQuery();

q.field(Organization.FIELD_PLAN).hasAnyOf(plans);

                return q.countAll();

       }

Anyone aware of a ground breaking change recently?

Thanks.

[Justin Lee]

OK.  I've figured out the problem and there are 2 possible fixes.  Your query is failing because you're passing an entity for your query when what's expected is a Key<Plan>.  The document structure has a DBRef which is what a Key would be converted to.  Because you're passing in the whole object, morphia is creating a document from that object and comparing the DBRef in mongo against that document which, of course, doesn't match.  If you create a Key<Plan> and query with that you'll see what you're expecting.

That's one fix. The other possible fix is that morphia should be smart enough to see that the structure of Org uses @Reference and convert that List<Plan> to a List<Key<Plan>> transparently.  While I lean slightly toward that, it has some drawbacks.  It introduces a bit more magic that can subtly violate expectations.  If I pass in a reference to an object that's been modified in memory, am I supposed to find all Orgs that reference a Plan that have a similar state?  Or do I really just want to find matches against the IDs of those Plans?  Passing in an object like that is not that far off of query by example and I'm not sure how badly we'd be violating expectations by silently creating Key<?>s for those referenced objects.

So close to a 1.0, I'm inclined to let things ride as they are:  you'd use a List<Key<Plan>> to query.  I'd rather not introduce such a subtle change now but I'm open to discussing that as longer term option if that's the consensus of how things should work.

[Patricio Echagüe]

I will try that. I also got a patch that fixes my problem and still make all tests pass.
The culprit was a commit made in July. I can send more info when I get to the office (shortly).

I'm ok passing a Key but what I don't like is that the query returns with no data and no exception is thrown. Making this issues hard to track.

Sent from my Nexus 4.

--
You received this message because you are subscribed to a topic in the Google Groups "Morphia" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/morphia/eieRfdv4ZXM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to morphia+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Patricio Echagüe]

I just tried passing a Key<Class,String> and still doesn't work.

Sent from my Nexus 4.

[Patricio Echagüe]

Justin, this is my PR https://github.com/mongodb/morphia/pull/568

[Justin Lee]

You need Key<Class, ObjectId>

You received this message because you are subscribed to the Google Groups "Morphia" group.
To unsubscribe from this group and stop receiving emails from it, send an email to morphia+u...@googlegroups.com.

[Patricio Echagüe]

Ok That works thanks. Let me know if the PR makes sense. I prefer that approach.

[Justin Lee]

I think we'll end up changing it so that Keys are transparently created in cases like this.  Talking it over with coworkers made it clear that anything else is kinda weird in a mongo sense.

[Patricio Echagüe]

Great. Thanks.