NPE due to something between e794813a and HEAD

[Salomon Brys]

Hi,

I had Objectify running perfectly on my app.

I am using objectify as a git submodule in my project and inserting sources directly in my project.

I was using the checkout e794813a and everything worked perfectly.

I've just tested to update to version HEAD (76dcb339) and then I took an arrow in the knee.

Here is the exact problem :

Query<Post> query = ofy().load().group(WithPoster.class, WithNetwork.class).type(Post.class).ancestor(key).order("-date").limit(limit);
QueryResultIterator<Post> it = query.iterable().iterator();
while (it.hasNext())
    posts.add(it.next());

I should point out that Post is a polymorphic kind and that the database currently contains only one child kind : MessagePost.

So here is the problem : when using last version of Objectify, the 8th it.next() returns null.

The eighth entity that should be returned has absolutely nothing different compared to its peers.

Weirder : it only crashes in production. Everything runs smoothly as it should be in dev server.

Of course, I have reversed to checkout e794813a.

So, do you have any clue of what's happening ?

Thanks,
Salomon BRYS

---

Salomon BRYS | Architecte Logiciel | Chief Geek Officer
Kick Your App
80 Rue des Haies - 75020 - Paris, France
+33 9 72 37 17 24 | +33 6 83 54 55 96 
sal...@kickyourapp.com
Linkedin

[Jeff Schnitzer]

I will look into this tonight.

Jeff

--
You received this message because you are subscribed to the Google Groups "objectify-appengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appen...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jeff Schnitzer]

Puzzling. I cannot imagine how any of the checkins since e794813a could possibly have an effect like that.  Take a look - there's just nothing relevant.  Most of the changes affect test classes only.  The only one that even looks interesting (adding distinct()) has zero logic impact on queries.

The only checkin that I could even imagine having an effect is building against SDK 1.7.4 instead of 1.7.2.  But that seems pretty far fetched.

Is this error (the null 8th value) perfectly reproducible in your production environment? Is there any chance there's something else going on in the data?  Or maybe you have local code changes that would follow a slightly different path between the two deployments?

There's really just nothing in those checkins that could possibly cause any behavior changes in queries. Either that or I'm blind - look at the diffs.

Jeff

On Wed, Feb 13, 2013 at 12:09 PM, Salomon Brys <sal...@kickyourapp.com> wrote:

--

[Salomon Brys]

OK, I sincerely don't understand what happened.

I looked at the diff before posting, to see if I could understand and I was like you... no clue.

And this morning I retry the exact same experiment, it it passes without any sort of problem, the 8th value is returned as it should be.

I have absolutely no clue what happened. I did not touch the entity classes. That's really weird.

I know it's not a memcache issue since yesterday I also tried to flush the memcache, without success.

This really is was a mystic bug (of Ka'aa).

I'm sorry I bothered you about this.

Salomon.

Bien cordialement,

Salomon BRYS

---

Salomon BRYS | Architecte Logiciel | Chief Geek Officer
Kick Your App
80 Rue des Haies - 75020 - Paris, France
+33 9 72 37 17 24 | +33 6 83 54 55 96 
sal...@kickyourapp.com
Linkedin