Version 1.3.1 von Google App Engine
Nach fast exakt 2 Monaten gibt es mit der Version 1.3.1 das erste Update der 1.3er Reihe: > - Datastore Query Cursors
http://code.google.com/appengine/docs/java/datastore/queriesandindexes.html#Query_Cursors
Transactional Tasks
Support for Custom Admin Console pages
Java Precompilation is now on by default
Developers can opt-out of precompilation by setting the flag in appengine-web.xml: <precompilation-enabled>
false</precompilation-enabled>New built-in support for unit testing (see appengine-testing.jar)
net.sf.jsr107package included as an alternative to the low-level Memcache API
javax.annotation.Resource/Resources added to the package whitelistNew „month“ and „synchronized“ syntax for Cron configuration
URLFetch supports asynchronous requests
appcfg.sh uses HTTPS for application deployment
appcfg.sh adds request_logs –append
Changes to the order queries without a specified sort order are returned
Only queries that use IN will see different results.
Added support for multiple != filters on the same property
Improved support for keys-only queries when using IN and != filters
Support for ETags, If-matches, If-not-matches HTTP Headers, as well as 304 status codes now available on static files (not yet available on the dev_appserver or Blobstore blobs)
Fixed issue where the maximum transform count was enforced for composite operations
Fixed issue with whitespace on the end of strings in web.xml
Fixed web.xml <error-page> entries for 404 error codes
Added validation prevent welcome-files with absolute paths
Fixed issue where cancelling a deployment in progress could unintentionally corrupt the SDK
Fixed issue with
QuotaService.getCpuTimeInMegaCycles()returning 0Fixed issue where JSP exceptions will be incorrectly cast causing a
ClassCastExceptionJDO/JPA Changes
Child object with custom pk column can’t be saved
Queries with multiple
contains()where one filter is on pk don’t workThrow exception when filtering or sorting by pk-id or pk-name fields
Throw exception when filtering or sorting by pk-id or pk-name fields
Store child keys in a multi-value property on the parent
Incorrect exception for multiple fields of same type
Non-persistent base classes do not work
Relationships in abstract base classes don’t work
Explicitly disallow multiple relationships of the same type
Occasional
ArrayOutOfBoundsIndexExceptionSupport inheritance
Support != queries
Support IN queries
Support datastore cursors
Inheritance is working for simple fields and embedded fields. Relationships in base classes are completely untested and probably do not work.
Cannot add child to existing one-to-many if parent has Long or unencoded
StringpkCan’t query by embedded fields at depth > 1
Positional parameters don’t work (JPQL)
Throw
JDOCanRetryExceptionwhen ConcurrentMod hit during txn commitRespect JDOQL/JPQL case sensitivity for keywords, in particular „count“
Put all native datastore types in the default fetch group
Empty
Setgets loaded from datastore asnullCannot remove element of one to many when parent has pk of type Long or unencoded
StringSevere problem when deleting a child object from an owned relationship (JDO)
NPE resulting from corrupt JDOQL query
Embedded, multi-value fields don’t work
Die Unterstützung eines Cursors gehört mit den größten Neuerungen. Zudem listet der Blog-Eintrag auf:
- Datastore Query Cursors – Cursors allow applications to save and ‚bookmark‘ their progress through a query, so that it can be resumed later. This works great in combination with paging URLs, as well as processing in the Task Queue API, but there are many other uses. Watch for an upcoming blog post that explores Cursors in the near future. They’re also really handy in the context of the next change…
- No more 1000 result limit – That’s right: with addition of Cursors and the culmination of many smaller Datastore stability and performance improvements over the last few months, we’re now confident enough to remove the maximum result limit altogether. Whether you’re doing a fetch, iterating, or using a Cursor, there’s no limits on the number of results.
- Reduced error rate with Automatic Datastore Retries – We’ve heard a lot of feedback that you don’t want to deal with the Datastore’s sporadic errors. In response, App Engine now automatically retries all datastore calls (with the exception of transaction commits) when your applications encounters a datastore error caused by being unable to reach Bigtable. Datastore retries automatically builds in what many of you have been doing in your code already, and our tests have shown it drastically reduces the number of errors your application experiences (by up to 3-4x error reduction for puts, 10-30x for gets).
