Group items tagged

Another way of solving the problem is to have a Horse object with a "farmKey" field like so: class Horse {  @PrimaryKey  Key mKey  Key farmKey } Then to get horses on a farm you'd do a query on Horse.kind with farmKey equal to your farm key.  (Keys only query would make this faster) What's nice about this approach is that you don't need Horse key at all, just create a Horse object, give it the farm key, and persist it without worrying about it.

> > so a Farm can have some horses. I'd like to create a new horse, then > > put it on a farm, in one transaction.

> This requires Horse to be a descendant of Farm to be in the same   > entity group.  Therefore a horse could not move farms unless you   > delete and recreate it with a new Key.

> I'm still curious where does "method" name come from? That is just "Get" of "Put" or "RunQuery" etc.    I have also checked   in an implementation of Nick Johnsons ApiProxyHook which logs all this   info: LoggingApiProxyDelegate.  Its handy for seeing how what rpc   calls are being made.  If you want to discuss Twig specifics probably   best to do that here http://groups.google.com/group/twig-persist

   private LocalServiceTestHelper helper =          new LocalServiceTestHelper(new   LocalDatastoreServiceTestConfig().setBackingStoreLocation(DS_PATH)); You could copy the WEB-INF/appegine-generated/local_db.bin file with   your data next to your test case and in a @Before method, delete the   old copy and copy a new one to DS_PATH.  You might also want to check   out LocalDatastoreServiceTestConfig().setNoStrage(true)

've been able to accomplish what you're doing with Selenium testing. If you're using GWT, then your integration testing and user acceptance probably won't be that far from each other.

> My question is this. What's the best way to use LocalServiceTestHelper > so that I can use my app like it has a persistent store? There is no > 'setUp' and 'tearDown' hooks like a JUnit test and the app runs in a > separate process within the IDE. (And in any case, I'm looking to do > integration testing where I want the state to be consistent across a > number of page requests.)

 Twig is an alternative to the standard   persistence interfaces JDO and JPA, specifically designed to make the   most of the underlying datastore's unique features.

Twig is the only interface to support direct unowned relationships so   your code is not dependent on low-level datastore classes.  It is the   only interface to support OR queries by merging together multiple   queries, sorting them and filtering out duplicates at the lowest level   for performance.

Async datastore calls are not yet part of the low-level API.  Twig   uses the underlying Protocol Buffer layer classes to call   ApiProxy.makeAsyncCall() instead of makeSyncCall.  All the code is   open source so you can check out how its done.

I have an Entity with an id type of Long, and the id gets filled in after I call makePersistent(). Here is what the code looks like:     GameEntity game = new GameEntity();    log.warning("before makePersistent id is " + game.getId());    pm.makePersistent(game);    log.warning("after makePersistent id is " + game.getId()); Here is a snippet of the GameEntity class: @PersistenceCapable(identityType = IdentityType.APPLICATION)public class GameEntity {    @PrimaryKey    @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)    private Long id; And the output shows what you'd expect: WARNING 6428 - before makePersistent id is nullWARNING 6444 - after makePersistent id is 6 UPDATE: It occurred to me belatedly that you might want an actual Key object. You can create that yourself if you have the id: public Key getKey() {    return KeyFactory.createKey(GameEntity.class.getSimpleName(), id);}