Google App Engine introduction and restrictions

Google App Engine is simply a free host space that supports the J2EE and Python runtime environments and a * .appspot.com second-level domain name. The biggest advantage is that it is free, whether it is CPU or bandwidth for ordinary small websites are more than enough. However, Gae has many restrictions. I would like to share with you the various restrictions I have encountered in the J2EE project on Gae.

The most prominent one is the sandbox runtime environment. The so-called sandbox is an independent runtime space, no matter what code is executed in this space, it will not affect other sandboxes and the entire system. In general, the general restriction of sandbox is that local files cannot be accessed, which is the same for Gae. Files cannot be written, but files uploaded along with the application can be read. All data must be stored and read by the database.

Speaking of databases, this is the least habit of Gae. Gae databases are not really relational databases. They are similar to databases implemented using bigtable in combination with distributed gfs. Instead of relational databases, they naturally cannot support complete SQL statements and some natural operations in relational databases. JDO (Java Data Object) and JPA must be used for data access on Gae. JDO is recommended, which is much more convenient than JPA. First, the maximum limit is that SQL statements only support select * and select _ key _, that is, only select operations, and must select all fields or select primary keys. No insert, delete, or update operations are supported. However, you can use the persistent layer operations provided by JDO to implement CRUD (create, Retrive, update, delete) of this data ). To use the Gae platform, you do not need to explicitly define the table scheme. Instead, you only need to directly define data objects. For specific definition methods, refer to the Gae document. Note that the primary key cannot be Int or long (note that l is capitalized ). A simple dataservice class implementing crud is provided:

Public class ArticleServiceImpl implements ArticleService {<br/> protected ArticleServiceImpl () {<br/>}</p> <p> public void create (Article article) {<br/> PersistenceManager pm = PMF. get (). getPersistenceManager (); <br/> try {<br/> pm. makePersistent (article); <br/>}finally {<br/> pm. close (); <br/>}</p> <p> public Article retrieve (String id) {<br/> PersistenceManager pm = PMF. get (). getPersistenceManager (); <br/> try {<br/> Article article = pm. getObjectById (Article. class, id); <br/> pm. detachCopy (article); <br/> return article; <br/>} catch (Exception e) {<br/> return null; <br/>} finally {<br/> pm. close (); <br/>}</p> <p> public void update (Article article) {<br/> PersistenceManager pm = PMF. get (). getPersistenceManager (); <br/> try {<br/> Article original = pm. getObjectById (Article. class, article. getId (); <br/> original. setCategoryid (article. getCategoryid (); <br/> original. setCategoryindex (article. getCategoryindex (); <br/> original. setContent (article. getContent (); <br/> original. setIndex (article. getIndex (); <br/> original. setPostdate (article. getPostdate (); <br/> original. setTitle (article. getTitle (); <br/> pm. makePersistent (original); <br/>}finally {<br/> pm. close (); <br/>}</p> <p> public void delete (String id) {<br/> PersistenceManager pm = PMF. get (). getPersistenceManager (); <br/> try {<br/> Article article = pm. getObjectById (Article. class, id); <br/> pm. deletePersistent (article); <br/>} finally {<br/> pm. close (); <br/>}< br/>

One by one analysis, the create method is the simplest, just pass the uploaded do to the persistent layer. Retrive uses the primary key to obtain data from the persistence layer, but the data is managed by the persistence layer. If persistentmanager is disabled, the object does not exist, so we need to detach the object. It is to let it out of the persistent layer, and the way to get out is to make a deep copy, that is, the detachcopy method. In the update method, you must note that although a new data object is imported, the makepersistent object cannot be directly uploaded. Otherwise, an exception is thrown. The correct operation is to first obtain the object from the persistence layer with the primary key of the new data object, and then assign the data of the new object to the old object just caught from the persistence layer, save the old object. Old data objects are always stored on the persistence layer. The new object only provides data. The delete method is also relatively simple, just deletepersistent.

Another very troublesome problem is that the limit (a, B) query of Gae data finds all the objects from 0 to B, and then discards the previous one, returns the following B-A objects. In addition, the limit of A and B is less than 1000, that is, if the maximum amount of data that can be reached by limit is less than 2000. This raises another question: how to paging a large amount of data? My solution is to add an index field for each data to indicate its location in the database. You can use conditional query on the index directly on the page. For possible data increase/decrease and modification, index consistency must be maintained each time. Although the cost is not small, it is still more efficient than limit and can exceed the limit of 2000 data entries.

The last question worth mentioning is the query on the date field. I tried to use the date format of various strings to try to do the conditional query on the date field, and all failed. I can't imagine a better solution: Using Long to store the date type. In Java, every date object can use the gettime method to return a unique long. That is to say, each date value can be uniquely matched with a long value and converted to each other. Therefore, it is much easier to store long data in the data:

Public List <Comment> listComments (int days) {<br/> PersistenceManager pm = PMF. get (). getPersistenceManager (); <br/> Date date = new Date (); <br/> Calendar ar calendar = Calendar ar. getInstance (); <br/> calendar. setTime (date); <br/> calendar. add (Calendar. DATE,-days); <br/> date = calendar. getTime (); <br/> Query query = pm. newQuery (Comment. class); <br/> query. setFilter (String. format ("postdate> = % s", date. getTime (); <br/> query. setOrdering ("postdate desc"); <br/> try {<br/> List <Comment> comments = (List <Comment>) query.exe cute (); <br/> pm. detachCopyAll (comments); <br/> return comments; <br/>}finally {<br/> query. closeAll (); <br/> pm. close (); <br/>}< br/>

The preceding example shows a database query operation for the comments in the last few days. Pay attention to the setfilter and detachcopyall methods.

For the Date type, we also need to mention that the time on GAE is the US time, we are the China time, and there is another problem of time zone conversion. My solution is to store all Date data and perform logical operations in accordance with the default time zone of GAE, and only convert the Date when it is output as a string:

Public String getLocalDateTimeStr (Date date) {<br/> DateFormat dateFormat = new SimpleDateFormat ("yyyy-MM-dd HH: mm: ss"); <br/> dateFormat. setTimeZone (TimeZone. getTimeZone ("GMT + 8"); // all date object is display in GMT + 8 time zone <br/> return dateFormat. format (date) <br/>}< br/>

The above are some of my experiences with this blog on GAE. I would like to share with you here. Mistakes are inevitable. please correct me.

 

Http://hzqtcblog.appspot.com/article.jsp? Articleid = dsntvawxgl