Question

When migrating the app from M/S datastore to HRD there are certain pitfalls to avoid. I had a question on one such specific area where it says “Entity ids of the same Kind are not always unique”.

To explain it further here’s an example.

1. Lets say I have 3 entities Customer, Contact, Address as below
2. Contact entity references Customer using customer key as
   com.google.appengine.api.datastore.Key
3. Address entity references Customer using customer key as Long

The 3 classes are:

public class Customer {
  @PrimaryKey
  @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
  private Key id;

  @Persistent
  private String name;
}

public class Contact {
  @PrimaryKey
  @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
  private Key id;

  @Persistent
  private String name;

  @Persistent
  private Key customerId;
}


public class Address {
  @PrimaryKey
  @Persistent(valueStrategy = IdGeneratorStrategy.IDENTITY)
  private Key id;

  @Persistent
  private String address;

  @Persistent
  private Long customerId;
}

All the entities are root entities.

Now when we migrate what will happen to customerId in Contact and Address entities? Will they still work or do we need to do anything special with them before migration?

Thanks!

Answer 1

What you are referring to is to do with how keys are built. An entity’s key will be made up from:

• Your application id
• The current namespace
• The hierarchy of parent(s) <-- this allows ids to be non-unique within a kind
• The Kind name
• The given key_name OR id

So for a key to be unique, any one of those parts could change. Within a single kind, within a single namespace within your app, the only time ids may not be unique is when you have set a parentfor that entity.

This means all your root entities as defined, will have unique ids/names.

If you need to guarantee that assigned ids are unique within a kind even across entities with an ancestor hierarchy, you could;

1. Re-think your design. If you are referring to entities by id accross entity groups without needing/having the parent, you might have applied entity groups somewhere they were not needed
2. You could allocateIds manually based on the root version of the Kind