Storm Manual
This is the detailed documentation for Storm. For a more hands-on approach, check out the [:Tutorial: Tutorial].
Databases
The create_database() function
The create_database() function has the following prototype:
database = create_database(uri)
The uri parameter may be either a URI string or a URI object. The following URIs are examples of acceptable syntax:
backend:database_name
backend://hostname/database_name
backend://hostname:port/database_name
backend://username:password@hostname/database_name
backend://hostname/database_name?option=value
backend://username@/database_name
MySQL
URIs
Dependencies
MySQL support depends on the [http://mysql-python.sf.net/ MySQLdb] module for Python.
PostgreSQL
URIs
Dependencies
PostgreSQL support depends on the [http://www.initd.org/tracker/psycopg/wiki/PsycopgTwo psycopg2] module for Python.
SQLite
Dependencies
SQLite support depends on the [http://www.initd.org/tracker/pysqlite/wiki/pysqlite pysqlite2] module for Python.
The Store interface
The ResultSet interface
Properties
What is a property in Storm
Common constructor parameters
Most properties accept the following properties. All of them are optional.
name: The column name in the database. Setting it allows the class attribute name and the column name in the database schema to differ. If unset, the name will be considered the same for the column and the class attribute.
primary: If true, this property is considered to map the primary key of the database table. Compound keys should be defined using the class-level __storm_primary__ attribute instead (see the section about compound keys for more information).
default: The default value for the property.
default_factory: A factory which returns default values for the property. This should be used when the default value is mutable.
Defining compound keys
To define a compound key in Storm, use the __storm_primary__ class-level attribute. It should be set to a tuple with the names of the properties composing the primary key. For example:
Table of properties vs. python vs. database types
Property |
Python |
PostgreSQL |
MySQL |
SQLite |
Bool |
bool |
BOOL |
TINYINT(1) |
anything(*) |
Int |
int, long |
SERIAL, BIGSERIAL, SMALLINT, INT, BIGINT |
TINYINT, SMALLINT, MEDIUMINT, INT, BIGINT |
anything(*) |
Float |
float |
FLOAT, REAL, DOUBLE PRECISION |
FLOAT, REAL, DOUBLE PRECISION |
anything(*) |
Decimal |
Decimal |
DECIMAL, NUMERIC, MONEY |
DECIMAL, NUMERIC |
anything(*) |
Unicode |
unicode |
TEXT, VARCHAR, CHAR |
TEXT, VARCHAR, CHAR |
anything(*) |
str |
BYTEA |
BLOB, BINARY, VARBINARY |
anything(*) |
|
Pickle |
any |
BYTEA |
BLOB, BINARY, VARBINARY |
anything(*) |
DateTime |
datetime |
TIMESTAMP |
DATETIME, TIMESTAMP |
anything(*) |
Date |
date |
DATE |
DATE |
anything(*) |
Time |
time |
TIME |
TIME |
anything(*) |
TimeDelta |
timedelta |
INTERVAL |
? |
anything(*) |
List |
list |
ARRAY[] |
? |
anything(*) |
(*) SQLite won't enforce data types, so they just must be formatted properly.
References
One-to-one
Many-to-one
Many-to-many
Using on_remote
The Reference interface
The ReferenceSet interface
Expressions
Managing stores
Working with multiple threads
Using a global function
Using a base class
Creating a backend
Testing
It's easy to test that Storm features are working with new backends. There are base test classes in tests/store/database.py and tests/store/base.py which may be inherited by database-specific test cases. Look at other backends to get a feeling of how it works.
If these tests pass with a new backend, you may be pretty sure that Storm is working fine with the created backend.