The `email` attribute is now usable in the same way as any other mapped attribute, including filter expressions, get/set operations, etc.:
{python}
- address = sess.query(EmailAddress).filter(EmailAddress.email == 'some address').one()
+ address = session.query(EmailAddress).filter(EmailAddress.email == 'some address').one()
address.email = 'some other address'
- sess.flush()
+ session.flush()
- q = sess.query(EmailAddress).filter_by(email='some other address')
+ q = session.query(EmailAddress).filter_by(email='some other address')
If the mapped class does not provide a property, the `synonym()` construct will create a default getter/setter object automatically.
We can now use the `Vertex` instances as well as querying as though the `start` and `end` attributes are regular scalar attributes:
{python}
- sess = Session()
+ session = Session()
v = Vertex(Point(3, 4), Point(5, 6))
- sess.save(v)
+ session.save(v)
- v2 = sess.query(Vertex).filter(Vertex.start == Point(3, 4))
+ v2 = session.query(Vertex).filter(Vertex.start == Point(3, 4))
The "equals" comparison operation by default produces an AND of all corresponding columns equated to one another. If you'd like to override this, or define the behavior of other SQL operators for your new type, the `composite()` function accepts an extension object of type `sqlalchemy.orm.PropComparator`:
'employees': relation(Employee)
})
-If we wanted to join from `Company` to not just `Employee` but specifically `Engineers`, using the `join()` method or `any()` or `has()` operators will by default create a join from `companies` to `employees`, without including `engineers` or `managers` in the mix. If we wish to have criterion which is specifically against the `Engineer` class, we can tell those methods to join or subquery against the full set of tables representing the subclass using the `of_type()` opertator:
+If we wanted to join from `Company` to not just `Employee` but specifically `Engineers`, using the `join()` method or `any()` or `has()` operators will by default create a join from `companies` to `employees`, without including `engineers` or `managers` in the mix. If we wish to have criterion which is specifically against the `Engineer` class, we can tell those methods to join or subquery against the full set of tables representing the subclass using the `of_type()` operator:
{python}
session.query(Company).join(Company.employees.of_type(Engineer)).filter(Engineer.engineer_info=='someinfo')
The first mapper created for a certain class is known as that class's "primary mapper." Other mappers can be created as well on the "load side" - these are called **secondary mappers**. This is a mapper that must be constructed with the keyword argument `non_primary=True`, and represents a load-only mapper. Objects that are loaded with a secondary mapper will have their save operation processed by the primary mapper. It is also invalid to add new `relation()`s to a non-primary mapper. To use this mapper with the Session, specify it to the `query` method:
- example:
+example:
- {python}
- # primary mapper
- mapper(User, users_table)
+ {python}
+ # primary mapper
+ mapper(User, users_table)
- # make a secondary mapper to load User against a join
- othermapper = mapper(User, users_table.join(someothertable), non_primary=True)
+ # make a secondary mapper to load User against a join
+ othermapper = mapper(User, users_table.join(someothertable), non_primary=True)
- # select
- result = session.query(othermapper).select()
+ # select
+ result = session.query(othermapper).select()
The "non primary mapper" is a rarely needed feature of SQLAlchemy; in most cases, the `Query` object can produce any kind of query that's desired. It's recommended that a straight `Query` be used in place of a non-primary mapper unless the mapper approach is absolutely needed. Current use cases for the "non primary mapper" are when you want to map the class to a particular select statement or view to which additional query criterion can be added, and for when the particular mapped select statement or view is to be placed in a `relation()` of a parent mapper.
a trigger for the ORM, allowing mappers to be compiled automatically
and will fire a `init_instance` event that `MapperExtension`s may
listen for. `MapperExtension`s can also listen for a
-`reconstruct_instance` event, analagous to the `reconstructor`
+`reconstruct_instance` event, analogous to the `reconstructor`
decorator above.
#### Extending Mapper {@name=extending}
##### Self-Referential Query Strategies {@name=query}
-Querying self-referential structures is done in the same way as any other query in SQLAlchemy, such as below, we query for any node whose `data` attrbibute stores the value `child2`:
+Querying self-referential structures is done in the same way as any other query in SQLAlchemy, such as below, we query for any node whose `data` attribute stores the value `child2`:
{python}
# get all nodes named 'child2'
- sess.query(Node).filter(Node.data=='child2')
+ session.query(Node).filter(Node.data=='child2')
On the subject of joins, i.e. those described in [datamapping_joins](rel:datamapping_joins), self-referential structures require the usage of aliases so that the same table can be referenced multiple times within the FROM clause of the query. Aliasing can be done either manually using the `nodes` `Table` object as a source of aliases:
{python}
# get all nodes named 'subchild1' with a parent named 'child2'
nodealias = nodes.alias()
- {sql}sess.query(Node).filter(Node.data=='subchild1').\
+ {sql}session.query(Node).filter(Node.data=='subchild1').\
filter(and_(Node.parent_id==nodealias.c.id, nodealias.c.data=='child2')).all()
SELECT treenodes.id AS treenodes_id, treenodes.parent_id AS treenodes_parent_id, treenodes.data AS treenodes_data
FROM treenodes, treenodes AS treenodes_1
{python}
# get all nodes named 'subchild1' with a parent named 'child2'
- {sql}sess.query(Node).filter(Node.data=='subchild1').\
+ {sql}session.query(Node).filter(Node.data=='subchild1').\
join('parent', aliased=True).filter(Node.data=='child2').all()
SELECT treenodes.id AS treenodes_id, treenodes.parent_id AS treenodes_parent_id, treenodes.data AS treenodes_data
FROM treenodes JOIN treenodes AS treenodes_1 ON treenodes_1.id = treenodes.parent_id
{python}
# get all nodes named 'subchild1' with a parent named 'child2' and a grandparent 'root'
- {sql}sess.query(Node).filter(Node.data=='subchild1').\
+ {sql}session.query(Node).filter(Node.data=='subchild1').\
join('parent', aliased=True).filter(Node.data=='child2').\
join('parent', aliased=True, from_joinpoint=True).filter(Node.data=='root').all()
SELECT treenodes.id AS treenodes_id, treenodes.parent_id AS treenodes_parent_id, treenodes.data AS treenodes_data
>>> 'shopping_carts' in meta.tables:
True
-To get direct access to 'shopping_carts', simply instantiate it via the `Table` constructor. `Table` uses a special contructor that will return the already created `Table` instance if it's already present:
+To get direct access to 'shopping_carts', simply instantiate it via the `Table` constructor. `Table` uses a special constructor that will return the already created `Table` instance if it's already present:
{python}
shopping_carts = Table('shopping_carts', meta)
>>> from sqlalchemy import create_engine
>>> engine = create_engine('sqlite:///:memory:', echo=True)
-The `echo` flag is a shortcut to setting up SQLAlchemy logging, which is accomplished via Python's standard `logging` module. With it enabled, we'll see all the generated SQL produced. If you are working through this tutorial and want less output generated, set it to `False`. This tutorial will format the SQL behind a popup window so it doesn't get in our way; just click the "SQL" links to see whats being generated.
+The `echo` flag is a shortcut to setting up SQLAlchemy logging, which is accomplished via Python's standard `logging` module. With it enabled, we'll see all the generated SQL produced. If you are working through this tutorial and want less output generated, set it to `False`. This tutorial will format the SQL behind a popup window so it doesn't get in our way; just click the "SQL" links to see what's being generated.
## Define and Create a Table {@name=tables}
### Using Aliases {@name=aliases}
-When querying across multiple tables, if the same table needs to be referenced more than once, SQL typically requires that the table be *aliased* with another name, so that it can be distinguished against other occurences of that table. The `Query` supports this most expicitly using the `aliased` construct. Below we join to the `Address` entity twice, to locate a user who has two distinct email addresses at the same time:
+When querying across multiple tables, if the same table needs to be referenced more than once, SQL typically requires that the table be *aliased* with another name, so that it can be distinguished against other occurrences of that table. The `Query` supports this most explicitly using the `aliased` construct. Below we join to the `Address` entity twice, to locate a user who has two distinct email addresses at the same time:
{python}
>>> from sqlalchemy.orm import aliased
- You can access and modify both the proxy and the backing relation. Changes in one are immediate in the other.
- The proxy acts like the type of the underlying collection. A list gets a list-like proxy, a dict a dict-like proxy, and so on.
- Multiple proxies for the same relation are fine.
-- Proxies are lazy, and won't triger a load of the backing relation until they are accessed.
+- Proxies are lazy, and won't trigger a load of the backing relation until they are accessed.
- The relation is inspected to determine the type of the related objects.
- To construct new instances, the type is called with the value being assigned, or key and value for dicts.
- A ``creator`` function can be used to create instances instead.
-Above, the ``Keyword.__init__`` takes a single argument ``keyword``, which maps conveniently to the value being set through the proxy. A ``creator`` function could have been used instead if more flexiblity was required.
+Above, the ``Keyword.__init__`` takes a single argument ``keyword``, which maps conveniently to the value being set through the proxy. A ``creator`` function could have been used instead if more flexibility was required.
Because the proxies are backed a regular relation collection, all of the usual hooks and patterns for using collections are still in effect. The most convenient behavior is the automatic setting of "parent"-type relationships on assignment. In the example above, nothing special had to be done to associate the Keyword to the User. Simply adding it to the collection is sufficient.
Session = sessionmaker(bind=some_engine)
# create a Session
- sess = Session()
+ session = Session()
# work with sess
myobject = MyObject('foo', 'bar')
- sess.add(myobject)
- sess.commit()
+ session.add(myobject)
+ session.commit()
# close when finished
- sess.close()
+ session.close()
Above, the `sessionmaker` call creates a class for us, which we assign to the name `Session`. This class is a subclass of the actual `sqlalchemy.orm.session.Session` class, which will instantiate with a particular bound engine.
Session.configure(bind=engine)
# work with the session
- sess = Session()
+ session = Session()
It's actually entirely optional to bind a Session to an engine. If the underlying mapped `Table` objects use "bound" metadata, the `Session` will make use of the bound engine instead (or will even use multiple engines if multiple binds are present within the mapped tables). "Bound" metadata is described at [metadata_tables_binding](rel:metadata_tables_binding).
connection = engine.connect()
# bind an individual Session to the connection
- sess = Session(bind=connection)
+ session = Session(bind=connection)
### Using create_session() {@name=createsession}
* *Persistent* - An instance which is present in the session and has a record in the database. You get persistent instances by either flushing so that the pending instances become persistent, or by querying the database for existing instances (or moving persistent instances from other sessions into your local session).
-* *Detached* - an instance which has a record in the database, but is not in any session. Theres nothing wrong with this, and you can use objects normally when they're detached, **except** they will not be able to issue any SQL in order to load collections or attributes which are not yet loaded, or were marked as "expired".
+* *Detached* - an instance which has a record in the database, but is not in any session. There's nothing wrong with this, and you can use objects normally when they're detached, **except** they will not be able to issue any SQL in order to load collections or attributes which are not yet loaded, or were marked as "expired".
Knowing these states is important, since the `Session` tries to be strict about ambiguous operations (such as trying to save the same object to two different sessions at the same time).
The above mapper specifies two relations, `items` and `customer`. The `items` relationship specifies "all, delete-orphan" as its `cascade` value, indicating that all `add`, `merge`, `expunge`, `refresh` `delete` and `expire` operations performed on a parent `Order` instance should also be performed on the child `Item` instances attached to it. The `delete-orphan` cascade value additionally indicates that if an `Item` instance is no longer associated with an `Order`, it should also be deleted. The "all, delete-orphan" cascade argument allows a so-called *lifecycle* relationship between an `Order` and an `Item` object.
-The `customer` relationship specifies only the "save-update" cascade value, indicating most operations will not be cascaded from a parent `Order` instance to a child `User` instance except for the `add()` operation. "save-update" cascade indicates that an `add()` on the parent will casade to all child items, and also that items added to a parent which is already present in the sessio will also be added.
+The `customer` relationship specifies only the "save-update" cascade value, indicating most operations will not be cascaded from a parent `Order` instance to a child `User` instance except for the `add()` operation. "save-update" cascade indicates that an `add()` on the parent will cascade to all child items, and also that items added to a parent which is already present in the session will also be added.
The default value for `cascade` on `relation()`s is `save-update, merge`.
The `Session` manages transactions across all engines associated with it. As the `Session` receives requests to execute SQL statements using a particular `Engine` or `Connection`, it adds each individual `Engine` encountered to its transactional state and maintains an open connection for each one (note that a simple application normally has just one `Engine`). At commit time, all unflushed data is flushed, and each individual transaction is committed. If the underlying databases support two-phase semantics, this may be used by the Session as well if two-phase transactions are enabled.
-Normal operation ends the transactional state using the `rolback()` or `commit()` methods. After either is called, the `Session` starts a new transaction.
+Normal operation ends the transactional state using the `rollback()` or `commit()` methods. After either is called, the `Session` starts a new transaction.
{python}
Session = sessionmaker()
- sess = Session()
+ session = Session()
try:
- item1 = sess.query(Item).get(1)
- item2 = sess.query(Item).get(2)
+ item1 = session.query(Item).get(1)
+ item2 = session.query(Item).get(2)
item1.foo = 'bar'
item2.bar = 'foo'
# commit- will immediately go into a new transaction afterwards
- sess.commit()
+ session.commit()
except:
# rollback - will immediately go into a new transaction afterwards.
- sess.rollback()
+ session.rollback()
A session which is configured with `autocommit=True` may be placed into a transaction using `begin()`. With an `autocommit=True` session that's been placed into a transaction using `begin()`, the session releases all connection resources after a `commit()` or `rollback()` and remains transaction-less (with the exception of flushes) until the next `begin()` call:
{python}
Session = sessionmaker(autocommit=True)
- sess = Session()
- sess.begin()
+ session = Session()
+ session.begin()
try:
- item1 = sess.query(Item).get(1)
- item2 = sess.query(Item).get(2)
+ item1 = session.query(Item).get(1)
+ item2 = session.query(Item).get(2)
item1.foo = 'bar'
item2.bar = 'foo'
- sess.commit()
+ session.commit()
except:
- sess.rollback()
+ session.rollback()
raise
The `begin()` method also returns a transactional token which is compatible with the Python 2.6 `with` statement:
{python}
Session = sessionmaker(autocommit=True)
- sess = Session()
- with sess.begin():
- item1 = sess.query(Item).get(1)
- item2 = sess.query(Item).get(2)
+ session = Session()
+ with session.begin():
+ item1 = session.query(Item).get(1)
+ item2 = session.query(Item).get(2)
item1.foo = 'bar'
item2.bar = 'foo'
{python}
Session = sessionmaker()
- sess = Session()
- sess.add(u1)
- sess.add(u2)
+ session = Session()
+ session.add(u1)
+ session.add(u2)
- sess.begin_nested() # establish a savepoint
- sess.add(u3)
- sess.rollback() # rolls back u3, keeps u1 and u2
+ session.begin_nested() # establish a savepoint
+ session.add(u3)
+ session.rollback() # rolls back u3, keeps u1 and u2
- sess.commit() # commits u1 and u2
+ session.commit() # commits u1 and u2
`begin_nested()` may be called any number of times, which will issue a new SAVEPOINT with a unique identifier for each call. For each `begin_nested()` call, a corresponding `rollback()` or `commit()` must be issued.
### Enabling Two-Phase Commit {@name=twophase}
-Finally, for MySQL, Postgres, and soon Oracle as well, the session can be instructed to use two-phase commit semantics. This will coordinate the commiting of transactions across databases so that the transaction is either committed or rolled back in all databases. You can also `prepare()` the session for interacting with transactions not managed by SQLAlchemy. To use two phase transactions set the flag `twophase=True` on the session:
+Finally, for MySQL, PostgreSQL, and soon Oracle as well, the session can be instructed to use two-phase commit semantics. This will coordinate the committing of transactions across databases so that the transaction is either committed or rolled back in all databases. You can also `prepare()` the session for interacting with transactions not managed by SQLAlchemy. To use two phase transactions set the flag `twophase=True` on the session:
{python}
engine1 = create_engine('postgres://db1')
# bind User operations to engine 1, Account operations to engine 2
Session.configure(binds={User:engine1, Account:engine2})
- sess = Session()
+ session = Session()
# .... work with accounts and users
# commit. session will issue a flush to all DBs, and a prepare step to all DBs,
# before committing both transactions
- sess.commit()
+ session.commit()
## Embedding SQL Insert/Update Expressions into a Flush {@name=flushsql}
{python}
Session = sessionmaker(bind=engine)
- sess = Session()
+ session = Session()
# execute a string statement
- result = sess.execute("select * from table where id=:id", {'id':7})
+ result = session.execute("select * from table where id=:id", {'id':7})
# execute a SQL expression construct
- result = sess.execute(select([mytable]).where(mytable.c.id==7))
+ result = session.execute(select([mytable]).where(mytable.c.id==7))
The current `Connection` held by the `Session` is accessible using the `connection()` method:
{python}
- connection = sess.connection()
+ connection = session.connection()
The examples above deal with a `Session` that's bound to a single `Engine` or `Connection`. To execute statements using a `Session` which is bound either to multiple engines, or none at all (i.e. relies upon bound metadata), both `execute()` and `connection()` accept a `mapper` keyword argument, which is passed a mapped class or `Mapper` instance, which is used to locate the proper context for the desired engine:
{python}
Session = sessionmaker()
- sess = Session()
+ session = Session()
# need to specify mapper or class when executing
- result = sess.execute("select * from table where id=:id", {'id':7}, mapper=MyMappedClass)
+ result = session.execute("select * from table where id=:id", {'id':7}, mapper=MyMappedClass)
- result = sess.execute(select([mytable], mytable.c.id==7), mapper=MyMappedClass)
+ result = session.execute(select([mytable], mytable.c.id==7), mapper=MyMappedClass)
- connection = sess.connection(MyMappedClass)
+ connection = session.connection(MyMappedClass)
## Joining a Session into an External Transaction {@name=joining}
trans = conn.begin()
# create a Session, bind to the connection
- sess = Session(bind=conn)
+ session = Session(bind=conn)
# ... work with session
- sess.commit() # commit the session
- sess.close() # close it out, prohibit further actions
+ session.commit() # commit the session
+ session.close() # close it out, prohibit further actions
trans.commit() # commit the actual transaction
-Note that above, we issue a `commit()` both on the `Session` as well as the `Transaction`. This is an example of where we take advantage of `Connection`'s ability to maintain *subtransactions*, or nested begin/commit pairs. The `Session` is used exactly as though it were managing the transaction on its own; its `commit()` method issues its `flush()`, and commits the subtransaction. The subsequent transaction the `Session` starts after commit will not begin until it's next used. Above we issue a `close()` to prevent this from occuring. Finally, the actual transaction is committed using `Transaction.commit()`.
+Note that above, we issue a `commit()` both on the `Session` as well as the `Transaction`. This is an example of where we take advantage of `Connection`'s ability to maintain *subtransactions*, or nested begin/commit pairs. The `Session` is used exactly as though it were managing the transaction on its own; its `commit()` method issues its `flush()`, and commits the subtransaction. The subsequent transaction the `Session` starts after commit will not begin until it's next used. Above we issue a `close()` to prevent this from occurring. Finally, the actual transaction is committed using `Transaction.commit()`.
When using the `threadlocal` engine context, the process above is simplified; the `Session` uses the same connection/transaction as everyone else in the current thread, whether or not you explicitly bind it:
engine = create_engine('postgres://mydb', strategy="threadlocal")
engine.begin()
- sess = Session() # session takes place in the transaction like everyone else
+ session = Session() # session takes place in the transaction like everyone else
# ... go nuts
{python}
>>> # call Session() the first time. the new Session instance is created.
- >>> sess = Session()
+ >>> session = Session()
>>> # later, in the same application thread, someone else calls Session()
- >>> sess2 = Session()
+ >>> session2 = Session()
>>> # the two Session objects are *the same* object
- >>> sess is sess2
+ >>> session is session2
True
Since the `Session()` constructor now returns the same `Session` object every time within the current thread, the object returned by `scoped_session()` also implements most of the `Session` methods and properties at the "class" level, such that you don't even need to instantiate `Session()`:
web request ->
call controller -> # call Session(). this establishes a new,
# contextual Session.
- sess = Session()
+ session = Session()
# load some objects, save some changes
- objects = sess.query(MyClass).all()
+ objects = session.query(MyClass).all()
# some other code calls Session, it's the
# same contextual session as "sess"
- sess2 = Session()
- sess2.add(foo)
- sess2.commit()
+ session2 = Session()
+ session2.add(foo)
+ session2.commit()
# generate content to be returned
return generate_content()
# bind User operations to engine 1, Account operations to engine 2
Session.configure(binds={User:engine1, Account:engine2})
- sess = Session()
+ session = Session()
### Horizontal Partitioning
or with `create_session()`:
{python}
- sess = create_session(extension=MySessionExtension())
+ session = create_session(extension=MySessionExtension())
The same `SessionExtension` instance can be used with any number of sessions.
>>> from sqlalchemy import create_engine
>>> engine = create_engine('sqlite:///:memory:', echo=True)
-The `echo` flag is a shortcut to setting up SQLAlchemy logging, which is accomplished via Python's standard `logging` module. With it enabled, we'll see all the generated SQL produced. If you are working through this tutorial and want less output generated, set it to `False`. This tutorial will format the SQL behind a popup window so it doesn't get in our way; just click the "SQL" links to see whats being generated.
+The `echo` flag is a shortcut to setting up SQLAlchemy logging, which is accomplished via Python's standard `logging` module. With it enabled, we'll see all the generated SQL produced. If you are working through this tutorial and want less output generated, set it to `False`. This tutorial will format the SQL behind a popup window so it doesn't get in our way; just click the "SQL" links to see what's being generated.
## Define and Create Tables {@name=tables}
{}
COMMIT
-Users familiar with the syntax of CREATE TABLE may notice that the VARCHAR columns were generated without a length; on SQLite, this is a valid datatype, but on most databases it's not allowed. So if running this tutorial on a database such as Postgres or MySQL, and you wish to use SQLAlchemy to generate the tables, a "length" may be provided to the `String` type as below:
+Users familiar with the syntax of CREATE TABLE may notice that the VARCHAR columns were generated without a length; on SQLite, this is a valid datatype, but on most databases it's not allowed. So if running this tutorial on a database such as PostgreSQL or MySQL, and you wish to use SQLAlchemy to generate the tables, a "length" may be provided to the `String` type as below:
{python}
Column('name', String(50))
[', ', 'm', 'z', '%@aol.com', '%@msn.com']
[(u'Wendy Williams, wendy@aol.com',)]
-Once again, SQLAlchemy figured out the FROM clause for our statement. In fact it will determine the FROM clause based on all of its other bits; the columns clause, the whereclause, and also some other elements which we haven't covered yet, which include ORDER BY, GROUP BY, and HAVING.
+Once again, SQLAlchemy figured out the FROM clause for our statement. In fact it will determine the FROM clause based on all of its other bits; the columns clause, the where clause, and also some other elements which we haven't covered yet, which include ORDER BY, GROUP BY, and HAVING.
## Using Text {@name=text}
[]
{stop}www@www.org
-Databases such as Postgres and Oracle which support functions that return whole result sets can be assembled into selectable units, which can be used in statements. Such as, a database function `calculate()` which takes the parameters `x` and `y`, and returns three columns which we'd like to name `q`, `z` and `r`, we can construct using "lexical" column objects as well as bind parameters:
+Databases such as PostgreSQL and Oracle which support functions that return whole result sets can be assembled into selectable units, which can be used in statements. Such as, a database function `calculate()` which takes the parameters `x` and `y`, and returns three columns which we'd like to name `q`, `z` and `r`, we can construct using "lexical" column objects as well as bind parameters:
{python}
>>> from sqlalchemy.sql import column
After you create a Mapper, all operations with that Mapper require the usage of an important object called a `Session`. All objects loaded or saved by the Mapper must be *attached* to a `Session` object, which represents a kind of "workspace" of objects that are loaded into memory. A particular object instance can only be attached to one `Session` at a time (but of course can be moved around or detached altogether).
-By default, you have to create a `Session` object explicitly before you can load or save objects. Theres several ways to manage sessions, but the most straightforward is to just create one, which we will do by saying, `create_session()`:
+By default, you have to create a `Session` object explicitly before you can load or save objects. There are several ways to manage sessions, but the most straightforward is to just create one, which we will do by saying, `create_session()`:
{python}
>>> session = create_session()
#### Interval
-The Interval type deals with `datetime.timedelta` objects. In Postgres, the native INTERVAL type is used; for others, the value is stored as a date which is relative to the "epoch" (Jan. 1, 1970).
+The Interval type deals with `datetime.timedelta` objects. In PostgreSQL, the native INTERVAL type is used; for others, the value is stored as a date which is relative to the "epoch" (Jan. 1, 1970).
#### Binary
### Dialect Specific Types {@name=dialect}
-Each dialect has its own set of types, many of which are available only within that dialect. For example, MySQL has a `BigInteger` type and Postgres has an `Inet` type. To use these, import them from the module explicitly:
+Each dialect has its own set of types, many of which are available only within that dialect. For example, MySQL has a `BigInteger` type and PostgreSQL has an `Inet` type. To use these, import them from the module explicitly:
{python}
from sqlalchemy.databases.mysql import MSEnum, MSBigInteger
Column('id', MSBigInteger)
)
-Or some postgres types:
+Or some PostgreSQL types:
{python}
from sqlalchemy.databases.postgres import PGInet, PGArray
projects / thirdparty / sqlalchemy / sqlalchemy.git / commitdiff
