Group items tagged

I’m trying to use the bulkuploader for a java program but am running into an interesting issue. My PrimaryKey property is a Long, and in java I can explicitly give them id numbers and they show in the data store as “id=xxx”. When I download the data via the appcfg.py I get a reasonably looking data file. If I reupload the same file it actually inserts things into the data store with key “name=xxx” and therefore doubles every one of my entries.

create a custom uploader using the file upload example provided on appengine’s java FAQ.

App Engine’s datastore is schemaless. That is – it is possible to have Entities of the same Kind with completely different sets of properties. Most of the time, this is a good thing. MySQL, for instance, requires a table lock to do a schema update. By being schema free, migrations can happen lazily, and application developers can check at runtime for whether a Property exists on a given Entity, then create or set the value as needed. But there are times when this isn’t sufficient. One use case is if we want to change a default value on Entities and grandfather older Entities to the new default value, but we also want the default value to possibly be null.

A join model is a data model that models the relationship between two other models. For example, you might have Person entities and Group entities, and you want Persons to be in Groups and Groups to "have" Persons. The relationship between Persons and Groups is one of Memberships. A Person is "in" a Group "through" a Membership. They may belong to multiple Groups, i.e. have multiple Memberships.

class Membership(db.Model): person = db.ReferenceProperty(Person) group = db.ReferenceProperty(Group)

If certain properties of your joined entities (Person and Group in this example) don't change much, but get queried often via the join model, you may find it worth caching those properties on the join model itself.

Just my 2 cents: I was "forced" to use an "unowned relationship" for my application because I had very large objects: My parent object "Journey" contained thousands of "JourneyPoints" in a List element. A call to "makePersistent" constantly hit the 30s deadline. By modeling it as an unowned relationship and distributing the parent key by hand to the JourneyPoints everything was fine again and the performance was very good.

You could create an entity group for this. Post:    data    category    sort UserPost:    user

if you can form the key_name for post and userpost like this Key('Post', '<data>') Key('Post', '<data>', 'UserPost', '<user>') Then you can perform a key_only query for a userpost and using the keys parents perform a get to retrieve the relevant userposts Adding new users incrementally to a Post is very simple and light weight. Deleting a Post would also require you to delete the UserPost children. These being in an entity group would provide for performing transactions... generally you wouldn't need to use them anyway... maybe when performing a full delete.

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.

You will only find "unowned relationships" terminology in Google docs. This "unowned relationships" in the GAE/J docs is where you have a field that is a "Key" or a Collection/Map/array of keys. So no *real* relation, just some implicit relation by that "key". You have to manage these keys yourself, and you tie your code to GAE/J by using them.

A reference property simply stores the unique key of the entity it references. So the mother and father entities could each contain a copy of the key corresponding to their child

Have you considered doing both? Then you could quickly get a list of computers a student owns by key OR use a query which returns results in some sorted order. I don't think maintaining a list of keys on the student model is as intimidating as you think.

The best option depends on your requirements. Here's a few solutions (I'm assuming you're using Python, since you didn't specify): If you need to do transactional updates on an entire tree, and you're not going to have more than about 1QPS of sustained updates to any one tree, you can use the built in support for heirarchial storage. When creating an entity, you can pass the "parent" attribute to specify a parent entity or key, and when querying, you can use the .ancestor() method (or 'ANCESTOR IS' in GQL to retrieve all descendants of a given entity. If you don't need transactional updates, you can replicate the functionality of entity groups without the contention issues (and transaction safety): Add a db.ListProperty(db.Key) to your model called 'ancestors', and populate it with the list of ancestors of the object you're inserting. Then you can easily retrieve everything that's descended from a given ancestor with MyModel.all().filter('ancestors =', parent_key). If you don't need transactions, and you only care about retrieving the direct children of an entity (not all descendants), use the approach outlined above, but instead of a ListProperty just use a ReferenceProperty to the parent entity. This is known as an Adjacency List. There are other approaches available, but those three should cover the most common cases.