# SQLAlchemy 0.4 Documentation

Multiple Pages | One Page
Version: 0.4.4 Last Updated: 03/11/08 20:04:34

### Overview

The SQLAlchemy SQL Toolkit and Object Relational Mapper is a comprehensive set of tools for working with databases and Python. It has several distinct areas of functionality which can be used individually or combined together. Its major API components, all public-facing, are illustrated below:

               +-----------------------------------------------------------+
               |             Object Relational Mapper (ORM)                |
               |                [tutorial]    [docs]                       |
               +-----------------------------------------------------------+
               +---------+ +------------------------------------+ +--------+
               |         | |       SQL Expression Language      | |        |
               |         | |        [tutorial]  [docs]          | |        |
               |         | +------------------------------------+ |        |
               |         +-----------------------+ +--------------+        |
               |        Dialect/Execution        | |    Schema Management  |
               |              [docs]             | |        [docs]         |
               +---------------------------------+ +-----------------------+
               +----------------------+ +----------------------------------+
               |  Connection Pooling  | |              Types               |
               |        [docs]        | |              [docs]              |
               +----------------------+ +----------------------------------+

Above, the two most significant front-facing portions of SQLAlchemy are the Object Relational Mapper and the SQL Expression Language. These are two separate toolkits, one building off the other. SQL Expressions can be used independently of the ORM. When using the ORM, the SQL Expression language is used to establish object-relational configurations as well as in querying.

back to section top

### Tutorials

- Object Relational Tutorial - This describes the richest feature of SQLAlchemy, its object relational mapper. If you want to work with higher-level SQL which is constructed automatically for you, as well as management of Python objects, proceed to this tutorial.
- SQL Expression Tutorial - The core of SQLAlchemy is its SQL expression language. The SQL Expression Language is a toolkit all its own, independent of the ORM package, which can be used to construct manipulable SQL expressions which can be programmatically constructed, modified, and executed, returning cursor-like result sets. It's a lot more lightweight than the ORM and is appropriate for higher scaling SQL operations. It's also heavily present within the ORM's public facing API, so advanced ORM users will want to master this language as well.

back to section top

### Reference Documentation

- Datamapping - A comprehensive walkthrough of major ORM patterns and techniques.
- Session - A detailed description of SQLAlchemy's Session object
- Engines - Describes SQLAlchemy's database-connection facilities, including connection documentation and working with connections and transactions.
- Connection Pools - Further detail about SQLAlchemy's connection pool library.
- Metadata - All about schema management using `MetaData` and `Table` objects; reading database schemas into your application, creating and dropping tables, constraints, defaults, sequences, indexes.
- Types - Datatypes included with SQLAlchemy, their functions, as well as how to create your own types.
- Plugins - Included addons for SQLAlchemy

back to section top

### Installing SQLAlchemy

Installing SQLAlchemy from scratch is most easily achieved with setuptools. (setuptools installation). Just run this from the command-line:

    # easy_install SQLAlchemy

This command will download the latest version of SQLAlchemy from the Python Cheese Shop and install it to your system.

Otherwise, you can install from the distribution using the `setup.py` script:

    # python setup.py install

### Installing a Database API

SQLAlchemy is designed to operate with a DB-API implementation built for a particular database, and includes support for the most popular databases:

- Postgres: psycopg2
- SQLite: pysqlite, sqlite3 (included with Python 2.5 or greater)
- MySQL: MySQLdb
- Oracle: cx_Oracle
- MS-SQL: pyodbc (recommended), adodbapi or pymssql
- Firebird: kinterbasdb
- Informix: informixdb

back to section top

### Checking the Installed SQLAlchemy Version

This documentation covers SQLAlchemy version 0.4. If you're working on a system that already has SQLAlchemy installed, check the version from your Python prompt like this:

    >>> import sqlalchemy
    >>> sqlalchemy.__version__
    0.4.0

back to section top

### 0.3 to 0.4 Migration

From version 0.3 to version 0.4 of SQLAlchemy, some conventions have changed. Most of these conventions are available in the most recent releases of the 0.3 series starting with version 0.3.9, so that you can make a 0.3 application compatible with 0.4 in most cases.

This section will detail only those things that have changed in a backwards-incompatible manner. For a full overview of everything that's new and changed, see WhatsNewIn04.

### ORM Package is now sqlalchemy.orm

All symbols related to the SQLAlchemy Object Relational Mapper, i.e. names like `mapper()`, `relation()`, `backref()`, `create_session()` `synonym()`, `eagerload()`, etc. are now only in the `sqlalchemy.orm` package, and not in `sqlalchemy`. So if you were previously importing everything on an asterisk:

    from sqlalchemy import *

You should now import separately from orm:

    from sqlalchemy import *
    from sqlalchemy.orm import *

Or more commonly, just pull in the names you'll need:

    from sqlalchemy import create_engine, MetaData, Table, Column, types
    from sqlalchemy.orm import mapper, relation, backref, create_session

back to section top

### BoundMetaData is now MetaData

The `BoundMetaData` name is removed. Now, you just use `MetaData`. Additionally, the `engine` parameter/attribute is now called `bind`, and `connect()` is deprecated:

    # plain metadata
    meta = MetaData()

    # metadata bound to an engine
    meta = MetaData(engine)

    # bind metadata to an engine later
    meta.bind = engine

Additionally, `DynamicMetaData` is now known as `ThreadLocalMetaData`.

back to section top

### "Magic" Global MetaData removed

There was an old way to specify `Table` objects using an implicit, global `MetaData` object. To do this you'd omit the second positional argument, and specify `Table('tablename', Column(...))`. This no longer exists in 0.4 and the second `MetaData` positional argument is required, i.e. `Table('tablename', meta, Column(...))`.

back to section top

### Some existing select() methods become generative

The methods `correlate()`, `order_by()`, and `group_by()` on the `select()` construct now return a new select object, and do not change the original one. Additionally, the generative methods `where()`, `column()`, `distinct()`, and several others have been added:

    s = table.select().order_by(table.c.id).where(table.c.x==7)
    result = engine.execute(s)

back to section top

### collection_class behavior is changed

If you've been using the `collection_class` option on `mapper()`, the requirements for instrumented collections have changed. For an overview, see Alternate Collection Implementations.

back to section top

### All "engine", "bind_to", "connectable" Keyword Arguments Changed to "bind"

This is for create/drop statements, sessions, SQL constructs, metadatas:

    myengine = create_engine('sqlite://')

    meta = MetaData(myengine)

    meta2 = MetaData()
    meta2.bind = myengine

    session = create_session(bind=myengine)

    statement = select([table], bind=myengine)

    meta.create_all(bind=myengine)

back to section top

### All "type" Keyword Arguments Changed to "type_"

This mostly applies to SQL constructs where you pass a type in:

    s = select([mytable], mytable.c.x=bindparam(y, type_=DateTime))

    func.now(type_=DateTime)

back to section top

### Mapper Extensions must return EXT_CONTINUE to continue execution to the next mapper

If you extend the mapper, the methods in your mapper extension must return EXT_CONTINUE to continue executing additional mappers.

back to section top