Google AppEngine from the start: Model

In the previous article, we found out what Google AppEngine is, what you can do with it, and created the simplest and most primitive application for GAE - helloworld with minimal support for user authentication. Let's try to expand this application, considering, incidentally, the capabilities of Google AppEngine.

Structure and architecture

Our previous application was extremely simple, and, as such, did not need any architecture. Now we are setting ourselves a more complex and more realistic task - accordingly, we should think about what will happen when the application starts to grow. Of course, our task is invented and no architecture is required for it either, but for example we will try to do everything “according to science”.







')

This is what our application will look like in terms of structure. Blue rectangles indicate that these pages are accessible and visible to all. Yellow means that its contents may change if a user session is active. Orange is completely closed from the outside world and can only be accessed by logging in before.



Two pages in the picture above will be provided to us by the GAE - namely, “Login with Google” and “Logout”. All that is required of us is:

1. To write the main page which will give some imputed information and offer to login
2. Write a version of the main page for users who have already logged in
3. Write a login-handler that will register the fact of login and redirect the user to the main page
4. Write a page of statistics that will show how many times the user logged into the system and when was the last time.

Where to start? As usual - from the very beginning.

Model

In our application, the data storage model will be quite simple, however, it seems to me that this will be quite enough to illustrate the possibilities of GAE Datastore. Suppose we need to store information about a user, namely, his ID, the date and time of the last visit, and the number of visits. In the language of GAE Datastore it will look like this:

	 #! / usr / bin / env python
	 # encoding: utf-8
	 "" "
	 model.py
	 $ Id: model.py 4 2010-01-25 12: 14: 48Z sigizmund $
	 Created by Roman Kirillov on 2010-01-25.
	 "" "

	 import datetime
	 from google.appengine.ext import db
	 from google.appengine.api import users


	 class Visitor (db.Model):
	     '' '
	     Simple object which uses Google DataStore persistence model
	     '' '

	     '' 'UserProperty encapsulates information about a Google's 
	     user account available to application.  It is set to
	     use current user as default user automatically
	     whever new object is created '' '
	     user = db.UserProperty (required = True, auto_current_user_add = True) 

	     '' 'DateTimeProperty uses standard date datetime.datetime
	     and it is set to auto-update to now () whenever record is saved '' '
	     lastVisit = db.DateTimeProperty (auto_now = True)

	     '' 'Very simple integer property with default value of 0' ''
	     hits = db.IntegerProperty (default = 0)

http://code.google.com/p/habr-gae-helloworld/source/browse/trunk/model.py



Let's figure out who is that. The Visitor class inherits from the standard GAE class google.appengine.ext.db.Model , which is an interface to Datastore - all classes that want to be persistent using this technology should extend this class. Our Visitor class has three data fields: user , lastVisit and hits . Consider them in detail, starting with the last.

• db.IntegerProperty hits encapsulates the usual integer data type. By default, all new objects of this class are assigned the value 0. Everything is simple:

       u = Visitor ()
       u.hits = 1
       # ...
       hitsCount = u.hits
  

  Working with such fields is absolutely transparent - as a rule, you use them in the same way as objects of the basic, integer type.
  
  
• lastVisit is like the previous one, db.DateTimeProperty encapsulates the built-in data type, only this time it is datetime.datetime . By and large, there is no difference - it works in the same way with a field as with the specified data type. The field is configured so that you do not need to manually update it - every time the record is saved, the field value is set to now() (in this case, this is reasonable).
• db.UserProperty user is the most interesting one used here. It encapsulates the GAE class of users.User - no need to store the user's email, no need to store a unique ID in case the email changes - it's all there. And naturally, this is exactly the class whose object you get by making users.get_current_user() . The settings of the field indicate that every time an object is created, the value of this field will be set according to the current user.

Working with our class is very simple: we create it as a regular object, set the fields we want to set (in this case, hits ) and save it in the Datastore:

     u = Visitor ()
     u.hits = 17
     u.put ()

This is sufficient for the object to be saved and available later as part of the entity Visitor . About how to search for objects by the value of a specific field, I will tell a little bit later - in the next part of the article. The sources of our test application are gradually gaining their haven here and will be laid out as they are written.

---

This was the second part of a series of articles about AppEngine. In the following parts we will get to the delicious - the actual writing of the controller and the presentation. Waiting for your comments, suggestions and questions.



PS please advise a good syntax highlighter for Python, which will work fine with Habr? tohtml.com which I have always used generates something incompatible with Parser.



Update: The third part - habrahabr.ru/blogs/gae/81933