Group items tagged

You must have two things in consideration: the appid and version must match, and you should enable datastore writes.

I propose two possiblities: Duplicate Line_Item. Line_Item appointment_key name price finished ... A Line_Item should have a finished state, when the item was finished or not by the employee. If an employee hadn't finished all line items, mark them as unfinished, create a new appointment and copy all items that were unfinished. You can index on the appointment_key field on all Line_Items, which is a Good Thing. However, the duplicated data may be a problem. Dynamic fields for Line_Item: Line_Item duplicate_key appointment_key name price finished ... Create a new field, duplicate_key, for Line_Item which points to another Line_Item or to null (reserve this key!). Null means that the Line_Item is original, any other value means that this Line_Item is a duplicate of the Line_Item the field points to. All fields of Line_Item marked as a duplicate inherit the fields of the original Line_Item, except the appointment_key: so it will take less storage. Also this solution should have appointment_key indexed, to speed up lookup times. This requires one additional query per duplicated Line_Item, which may be a problem. Now, it's a clear choice: either better speed or better storage. I would go for the first, as it reduces complexity of your model, and storage is never a problem with modern systems. Less complexity generally means less bugs and less development/testing costs, which justifies the cost of the storage requirement.

How do I handle multipart form data? or How do I handle file uploads to my app? You can obtain the uploaded file data from a multipart form post using classes from the Apache Commons FileUpload package. Specifically you may want to use FileItemStream, FileItermIterator and ServletFileUpload as illustrated below. If you see a java.lang.NoClassDefFoundError after starting your application, make sure that the Apache Commons FileUpload JAR file has been copied to your war/WEB-INF/lib directory and added to your build path. import org.apache.commons.fileupload.FileItemStream;import org.apache.commons.fileupload.FileItemIterator;import org.apache.commons.fileupload.servlet.ServletFileUpload;import java.io.InputStream;import java.io.IOException;import java.util.logging.Logger;import javax.servlet.ServletException;import javax.servlet.http.HttpServlet;import javax.servlet.http.HttpServletRequest;import javax.servlet.http.HttpServletResponse;public class FileUpload extends HttpServlet {  private static final Logger log =      Logger.getLogger(FileUpload.class.getName());  public void doPost(HttpServletRequest req, HttpServletResponse res)      throws ServletException, IOException {    try {      ServletFileUpload upload = new ServletFileUpload();      res.setContentType("text/plain");      FileItemIterator iterator = upload.getItemIterator(req);      while (iterator.hasNext()) {        FileItemStream item = iterator.next();        InputStream stream = item.openStream();        if (item.isFormField()) {          log.warning("Got a form field: " + item.getFieldName());        } else {          log.warning("Got an uploaded file: " + item.getFieldName() +                      ", name = " + item.getName());          // You now have the filename (item.getName() and the          // contents (which you can read from stream).  Here we just          // print them back out to the servlet output stream, but you          // will probably want to do something more interesting (for          // example, wrap them in a Blob and commit them to the          // datastore).          int len;          byte[] buffer = new

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

The mapper API isn't just limited to mapping over datastore entities, either. You can map over lines in a text file in the blobstore, or over the contents of a zip file in the blobstore. It's even possible to write your own data sources

An end cursor allows you to specify when you want a query to stop. A cursor represents a query start position - an end cursor is another position. This lets you take, say, 10k entities, break them up into 100 "chunks", then do task queue or other background operations on them. Unlike using an offset (cursor +100), this method solves the case of new Entities being inserted, since you're not working with a cursor +100 Entities. You're working with all the Entities between startCursor and endCursor.

One option is to create a model User in your own application, one of the things it contains would be the google user object.  In this case, you have your own ID generated by each instance of your Model, for each User. EJ: class User(db.Model):         googleUser = db.UserProperty()

IDs aren't even unique within a kind; they're unique within a kind and entity group. The reason they're not sequential is that an instance is allocated a large block of IDs, and unused ones aren't assigned to later instances