Objectify 4.0b3 released

[Jeff Schnitzer]

Objectify 4.0b3 should now be in maven central.

Some notes:

 * Objectify now has a dependency - google guava. I'm just tired of living without it. If you're using maven, this will automatically be included.

 * This release includes "live" Ref behavior - calling get() will get the value, even if you didn't @Load it. @Load is now almost purely a performance consideration.

 * Note that Ref.getValue() works differently; it will return null if it was not loaded. This will make a lot of sense if you are in the habit of json-serializing object graphs.

 * load() operations now return a LoadResult<?> instead of a Ref<?>. The API is mostly compatible with Ref<?>. However, I deprecated get() to try to push everyone to use now() instead. I think it reads cleaner.

 * Ref<?> in GWT works about as well as Key<?> now. You can pass @Load-ed object graphs back to the client. Submitting from client to server is problematic though, and will continue to be until this issue is addressed: https://code.google.com/p/google-web-toolkit/issues/detail?id=3303  I'm not holding my breath.

 * I'm still updating the documentation.

 * If there are no major problems with this build, it will become the official 4.0 release sometime later this week.

Jeff

[Eurig Jones]

Jeff. I have been using 4.0b3  as of about 5 days ago from repository in production and I have had no issues with it as yet.

[Eurig Jones]

Actualy I have found a potential bug. I'm running this line:

OfyService.ofy().load().type(Game.class).filter("associatedPlayers", username).filter("result", null).list();

When I expect this to return 0, it sometimes returns a list of size 1 with a null at index 0;

[Eurig Jones]

I have tested with 4.0b3 release jar and same issue. I can reproduce this with my code by:

1. Request fetches list(). Empty list and no null at index 0.
2. Next request creates an object.
3. Next request deletes the object.
4. Last request fetches again list(), and this time the null appears at index 0.

Hope that is of help.

On Sunday, 5 May 2013 05:11:28 UTC+3, Jeff Schnitzer wrote:

[Jeff Schnitzer]

Wow, excellent catch! This is probably a longstanding issue in Ofy4; you're seeing the combination of eventual consistency (which returns deleted entities) and negative caching in memcache.

I have added some test cases around this and should have a solution this afternoon.

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.
 
 

[Eurig Jones]

I've also found another possible bug that is possibly related but at this time I have not managed to find any reproducible steps.

Basically sometimes when I create an object in a request, then a request very soon after I fetch a list which I expect this object to be in, but it's not. But if I wait a good few seconds later and the list appears as it should.

Hope that vaguely represents something to you :-/

Thanks!

To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appengine+unsub...@googlegroups.com.

[Jeff Schnitzer]

This is the eventually-consistent nature of the datastore, and there is no way around that short of adjusting your data model to create strong consistency (ie, use ancestor() queries).

Objectify can protect you by hiding entities that it knows were deleted. Objectify can't magically insert objects into query results which were not present in the query result set.

Jeff

To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appen...@googlegroups.com.

[Eurig Jones]

I understand. This is not a big deal for me as at least a while would occur between these two requests. But this is using the local datastore. Do you think the local datastore is potentially emulating the nature of the real datastore in this case?

Anyway, not a big deal :-)

To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appengine+unsubscribe...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jeff Schnitzer]

Yes, the local datastore emulates HRD behavior.

Jeff

To unsubscribe from this group and stop receiving emails from it, send an email to objectify-appen...@googlegroups.com.

[Freddy Boucher]

It works perfectly with GWT!

THX a lot.

Good job.

On Sunday, May 5, 2013 4:11:28 AM UTC+2, Jeff Schnitzer wrote:

Objectify 4.0b3 should now be in maven central.

 * Ref<?> in GWT works about as well as Key<?> now. You can pass @Load-ed object graphs back to the client. Submitting from client to server is problematic though, and will continue to be until this issue is addressed: https://code.google.com/p/google-web-toolkit/issues/detail?id=3303  I'm not holding my breath.

Jeff

[Chad Vincent]

Did 4.0b2 or 4.0b3 change the behavior of instantiating Objectify?

I'm using the OfyService model and after upgrading from 4.0b1 I'm now getting:

 Uncaught exception from servlet

java.lang.NoClassDefFoundError: Could not initialize class com.stuff.datastore.OfyService

Class:

public class OfyService extends ObjectifyService {

static {

ObjectifyService.factory().begin();

// All models must be listed here for Objectify to know how to handle them.

register(Entity1.class);

register(Entity2.class);

}

public static Objectify ofy() {

return ObjectifyService.ofy();

}

public static ObjectifyFactory factory() {

return ObjectifyService.factory();

}

}

[Chad Vincent]

Nevermind.  I apparently had an embedded map that needed the @EmbedMap annotation.

[alexh]

Does this emulating of the HRD happen by default? I've always noticed when the local app engine environment starts it says master/slave.

[INFO] INFO: Local Datastore initialized: 

[INFO] Type: Master/Slave

I have tried the following to no avail.

-Ddatastore.default_high_rep_job_policy_unapplied_job_pct=20

https://developers.google.com/appengine/docs/java/tools/devserver

I'm using the appengine-maven-plugin so perhaps there's a different (obscure) way of doing this.

[Eurig Jones]

You can change it to HRD local datastore in your project properties. If the checkbox for HRD is greyed out (like mine was) You can go to the (dot) .project file in the project folder and edit the boolean there.

[Jeff Schnitzer]

Sorry about that, I should have mentioned the change. I hope the exception is clear.

At some point in the future the standard embedding behavior will use EmbeddedEntity. The old (aka current) form of embedding (with properties named with dots in the middle) will always require some sort of annotation, like @Embed or @EmbedMap.

Jeff

--

[Chad Vincent]

> Sorry about that, I should have mentioned the change. I hope the exception is clear.

It is.  I didn't get it in the server-side stack trace, only in dev mode.  (I was testing the Ofy update and an update to a Cron handler.)

--
You received this message because you are subscribed to a topic in the Google Groups "objectify-appengine" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/objectify-appengine/2GIbvzzHysE/unsubscribe?hl=en.
To unsubscribe from this group and all its topics, send an email to objectify-appen...@googlegroups.com.

[Jon Sawyer]

Jeff,

Any chance you'll reconsider the dependency on Guava, considering your recent performance comments in the appengine group? Though I agree with you on the conveniences, I've removed Guava from my app solely because of the performance costs.

Looks like I'm stuck at 4.0b1 for now...

Jon

[Jeff Schnitzer]

I do a preposterous amount of filtering, transformation, partitioning, and concatenation with the guava collections. Previously I was doing a lot of it by hand, and now there's quite a lot more. I'm not going back to doing it by hand. If GAE meant I could not use essential tools like guava, I really would give up on GAE.

Have you measured the impact on startup time of having guava on the classpath? What is it? I would be genuinely surprised 

I don't know how easy it is to separate and repackage just the collections. It's a total hack but I'm not averse to it. I have dependencies on the 'base' package (Function, Predicate, things like that) too. My guess is that it's not seamless, but try it out and let me know.

Jeff

--

[Jeff Schnitzer]

On Thu, May 16, 2013 at 9:31 PM, Jeff Schnitzer <je...@infohazard.org> wrote:

Have you measured the impact on startup time of having guava on the classpath? What is it? I would be genuinely surprised 

The complete sentence is "I would be genuinely surprised if that one jar made a massive difference - I load a lot of jars in my app and the impact of each one individually seems small." 

[Jeff Schnitzer]

This turned out to be rather difficult to solve while keeping the cursor behavior correct, but the fix is finally in master.

Jeff