Comments on: Reviewing Google AppEngine for Java (Part 2)

By: David Westbrook

David Westbrook — Sat, 05 Nov 2011 19:38:00 +0000

Useful article. FYI, couple places in last couple of paragraphs you refer to “Google BigMap”. Don’t you mean BigTable? Even though – to be honest – BigMap might be a more fitting name.

By: ip2cntry – ex-appengine app (mainly JAX-RS)

ip2cntry – ex-appengine app (mainly JAX-RS) — Sat, 26 Jun 2010 14:39:12 +0000

[...] And guess what… AppEngine does not support multiple “less/more than” operands in one query! If you think hard about what BigTable is, it does make some sense. More information about “GQL” can be found here: http://code.google.com/appengine/docs/python/datastore/gqlreference.html All the restrictions about the Queries you can do are documented here – some are really counter intuitive when you come from an RDBMS enviroment… Ah well Oh, and yet another great link about GAE limitations. [...]

By: Florin

Florin — Sun, 28 Feb 2010 07:52:00 +0000

I had no idea. I gave up GAE back then but it’s not encouraging…

By: Sutikshan

Sutikshan — Fri, 26 Feb 2010 04:59:42 +0000

The set of problems you struggled with, I guess, every GAE sarter will fight with these…After 7 months of your post we are still not able to find bulk uploader for Java, (and no time to learn another new language python…may be too much for person coming from .net world)…

By: Larry Cable

Larry Cable — Fri, 11 Sep 2009 23:43:35 +0000

I have to agree with your assesment … I have been working on the prototype of a website app that wants to present a large (22m) db to users …

I gave up on JPA, I found that the datanucleus/bigtable implementation was just to quirky to get working, so I switched to JDO which is much more robust relatively.

the lack of a bulk uploader is a PITA, I have written one using HTTP form post and JDO to persist
the entities …

becaus each entity is mapped to it’s own entity group you cannot tx more than one of them at a
time … so you resort to makePersistentAll()
but that has a 500 object limit per call, and even
then you hit the 5 sec data store timeout … so
you can only persist about 250 or so …

then …

of course you hit then 30sec per request limit!

frankly I dont think you can easily host a reasonable application that wants a reasonably sized db behind it …

thiking of switching to EC2 …

By: houwie

houwie — Wed, 22 Jul 2009 05:49:12 +0000

JPA 1-N and N-1 works

By: Bart

Bart — Wed, 10 Jun 2009 12:04:14 +0000

I agree with Zvika. What’s the use of such an incompatible solution? I’d say Google should start by complying with existing standards (like JEE). After they’ve done so, that’s the time to come up with new and exiting things.

By: cease

cease — Tue, 09 Jun 2009 18:37:33 +0000

http://code.google.com/appengine/articles/gae_backup_and_restore.html

backup and restore.

cron jobs and memcache are supported, not sure how well

By: Zvika

Zvika — Mon, 08 Jun 2009 23:37:00 +0000

thanks,
I really enjoyed reading your adventures in the GAE(J) land.

instead of using a shell script to break the data uploading process into manageable pieces, I’d use a META REFRESH so that each page loads the next one. this way you can also be sure that upload chunks get executed sequentially without wasting any time between requests.

Other than that, On the whole, GAE looks to me like a piece of c**p. Useless for anything other than fun(doubt that, too):
jpa limitations blow (same as the python version, btw) and all these quirks, memory errors and missing classes – sheeeesh! like the modifications the Groovy team had to put into their latest version in order to be “gae compatible”. what’s that, then? load of bullocks. not to say that Google owes anything to anyone, after all it’s a free service and all, but still, it reminded me of IE’s applet support
Seems like Google is making a (bad) habbit out of breaking and slicing the Java platform with all their new and exiting technologies: GWT, Android, and now this. Very nice way to contribute back :\. it’s all abomination if you ask me – thanks but no thanks.