Group items tagged

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.

To get the development environment working the plugin also requires access to the unzipped SDK as packaged by Google. The plugin tries to help you set this up (“gae:unpack”) but that failed for me. I was able to get stuff working by manually unzipping the SDK artifact downloaded directly from Google to the following directory: ~/.m2/repository/com/google/appengine/appengine-java-sdk/1.3.0/appengine-java-sdk-1.3.0

You’ll also notice in our appengine-web.xml that we substitute in our application name. By default this comes from the properties section of the pom.xml file (line 11).

this tip can cut a few hundred milliseconds or more off of your cold start time. Using JSPs slows you down in two ways: If you have a file with a .jsp extension, anywhere in your website directory, appcfg will detect that you use JSP, and it will add 8 libraries that are used for processing JSPs into your lib directory before uploading to the app engine.  These libraries total two megabytes in size, and simply having them in your lib directory slows your cold starts down by a few hundred milliseconds. If you are interested in what libraries these are, you can see them in the temporary folder appcfg creates while uploading your app. The first JSP file accessed after a cold start, even an empty one, will take a few hundred additional milliseconds to be processed.  I'm not sure what causes this, maybe it has to do with initializing the JSP processor.

Just set up remote_api for your app using the directions here - notably the tip: Tip: If you have a Java app, you can use the Python bulkloader.py tool by installing the Java version of the remote_api handler, which is included with the Java runtime environment. The handler servlet class is com.google.apphosting.utils.remoteapi.RemoteApiServlet. Then, use the Python bulkloader with --dump or --restore.

a plugin is just a bunch of files as is accurately described in the docs and these files go in certain places in your application's folders in order to be used as is also accurately described in the docs.

1) Show the plugins.groovy and routes.groovy files in the WEB-INF folder in the Gaelyk project diagram. They are currently absent from the diagram. 2 Put a star or some other icon next to the mandatory plugins folder and the 2 mandatory plugin files (plugins.groovy and the plugin descriptor file) in the diagram. This will help show that one just needs to mix in in these files with the rest of their own project's files.

Every entity has a key that is unique over all entities in App Engine. A complete key includes several pieces of information, including the application ID, the kind, and an entity ID. (Keys also contain information about entity groups; see Transactions for more information.) An object's key is stored in a field on the instance. You identify the primary key field using the @PrimaryKey annotation. The app can provide the ID portion of the key as a string when the object is created, or it can allow the datastore to generate a numeric ID automatically. The complete key must be unique across all entities in the datastore. In other words, an object must have an ID that is unique across all objects of the same kind and with the same entity group parent (if any). You select the desired behavior of the key using the type of the field and annotations. If the class is used as a "child" class in a relationship, the key field must be of a type capable of representing an entity group parent: either a Key instance, or a Key value encoded as a string. See Transactions for more information on entity groups, and Relationships for more information on relationships. Tip: If the app creates a new object and gives it the same string ID as another object of the same kind (and the same entity group parent), saving the new object overwrites the other object in the datastore. To detect whether a string ID is already in use prior to creating a new object, you can use a transaction to attempt to get an entity with a given ID, then create one if it doesn't exist. See Transactions. There are 4 types of primary key fields:

list properties are indexed as 'multiply valued properties', with one index row per list entry. The index you specify should work fine.

I have a class which can contain many small elements in a list. Looks like: public class Farm {    private ArrayList<Horse> mHorses;} just wondering what will happen if the mHorses array grew to something crazy like 15,000 elements. I'm assuming that trying to write and read this from the datastore would be crazy, because I'd get killed on the serialization process. It's important that I can get the entire array in one shot without paging, and each Horse element may only have two string properties in it, so they are pretty lightweight: public class Horse {    private String mId;    private String mName;} I don't need these horses indexed at all. Does it sound reasonable to just store the mHorse array as a raw Text field, and force my clients to do the deserialization? Something like: public class Farm {    private Text mHorsesSerialized;} then whenever the client receives a Farm instance, it has to take the raw string of horses, and split it in order to reinstantiate the list, something like: // GWT client perhapsFarm farm = rpcCall.getMyFarm();String horsesSerialized = farm.getHorses();String[] horseBlocks = horsesSerialized.split(",");for (int i = 0; i < horseBlocks.length; i++) {    // .. continue deserializing the individual objects ...} yeah...

You can optimise it further, however: For each favorite, create a 'UserFavorite' entity as a child entity of the relevant Story entry (or equivalently, as a child entity of a UserInfo entry), with the key name set to the user's unique ID. This way, you can determine if a user has favorited a story with a simple get: UserFavorite.get_by_name(user_id, parent=a_story) get operations are 3 to 5 times faster than queries, so this is a substantial improvement.