ich that data class should be mapped. The data class will have attributes automatically added to it that correspond to the columns of your database table. Thus, the User class now has User.user_id, User.name, User.age, andUser.password. The Email class now has Email.email_id, Email.address, and Email.user_id.
session = create_session()
SQLAlchemy is capable of automatically keeping track of the data objects you create, and any changes you make to their attributes. This is done using Session objects, which do a lot of the behind-the-scenes work for you. Usually, you'll only need one Session object. SQLAlchemy could create it for you, but there are times when you'll want to be able to access the Session object directly. So SQLAlchemy follows the Python principle that "Explicit is better than implicit" and requires you to create your own Session object. At least, that's the default behavior: there are advanced features that let you have a "default Session context", and sometimes that's exactly what you want. However, it's best to learn the explicit way of doing things first; learning the advanced features can wait until you're comfortable with SQLAlchemy's way of doing things.
New in 0.2: Session objects replace the objectstore object from SQLAlchemy 0.1. The objectstore.commit() method (whose name was confusingly similar to the commit() method of database transactions) has been replaced by session.flush(). Session objects also have a couple of other differences, which we'll get to in a moment.
mary = session.query(User).selectfirst(users.c.name=='Mary')
Now that we've created a Session object, we can use it to load some data from our database. Now at first glance, the above line of code looks a little overcomplicated. You might be wondering why it isn't something simpler, like "session.selectfirst(users.c.name=='Mary')". The answer is that SQLAlchemy needs to know what class you're trying to create instances of. Here it might be possible to guess based on the fact that the selectfirst() criteria are specifying a column from the users table. But there's a Python principle that says, "In the face of ambiguity, refuse the temptation to guess." Because what if that guess is wrong? What if you're trying to load all the email addresses belonging to people named Mary? By forcing you to be explicit about which data class you want, SQLAlchemy avoids the possibility of guessing wrong.
Incidentally, the session.query(YourClass) call creates a Query object that you could save and reuse later. This can save a lot of typing if you have multiple select() calls to make.
New in 0.2: In SQLAlchemy 0.1, you would have called selectfirst() on the usermapper object. In SQLAlchemy 0.2, select() (and all related functions such as selectfirst()) are called on Query objects instead.
mary.age += 1
Now that we have an instance of the data class (in the object "mary"), we can manipulate its attributes just like a normal object. SQLAlchemy will keep track of the changes we make, but won't actually send them to the database right away. To send our changes to the database, we need to ...
session.flush()
... call the session.flush() method. This will take all the changes we've made to our data objects, and "flush" those changes out to the database. If we've made multiple changes, some of which depend on other changes (e.g., adding a new user and several email addresses for that user), SQLAlchemy is smart enough to write the SQL statements in the correct order. SQLAlchemy also wraps the entire set of SQL statements in a data