Class s.s.Store(object):

Get the Store that the object is associated with.

If the given object has not yet been associated with a store, return None.

Execute a basic query.

This is just like storm.database.Database.execute, except that a flush is performed first.

Close the connection.

Commit all changes to the database.

This invalidates the cache, so all live objects will have data reloaded next time they are touched.

Roll back all outstanding changes, reverting to database state.

Get object of type cls with the given primary key from the database.

If the object is alive the database won't be touched.

Parameters	cls	Class of the object to be retrieved.
	key	Primary key of object. May be a tuple for composed keys.
Returns	The object found with the given primary key, or None if no object is found.

Perform a query.

Some examples:

   store.find(Person, Person.name == u"Joe") --> all Persons named Joe
   store.find(Person, name=u"Joe") --> same
   store.find((Company, Person), Person.company_id == Company.id) -->
       iterator of tuples of Company and Person instances which are
       associated via the company_id -> Company relation.

Parameters	cls_spec	The class or tuple of classes whose associated tables will be queried.
	args	Instances of Expr.
	kwargs	Mapping of simple column names to values or expressions to query for.
Returns	A ResultSet of instances cls_spec. If cls_spec was a tuple, then an iterator of tuples of such instances.

Specify tables to use explicitly.

The find method generally does a good job at figuring out the tables to query by itself, but in some cases it's useful to specify them explicitly.

This is most often necessary when an explicit SQL join is required. An example follows:

   join = LeftJoin(Person, Person.id == Company.person_id)
   print list(store.using(Company, join).find((Company, Person)))

The previous code snippet will produce an SQL statement somewhat similar to this, depending on your backend:

   SELECT company.id, employee.company_id, employee.id
   FROM company
   LEFT JOIN employee ON employee.company_id = company.id;

Returns

A TableSet, which has a find method similar to Store.find.

Add the given object to the store.

The object will be inserted into the database if it has not yet been added.

The added event will be fired on the object info's event system.

Remove the given object from the store.

The associated row will be deleted from the database.

Reload the given object.

The object will immediately have all of its data reset from the database. Any pending changes will be thrown away.

Set an object or all objects to be reloaded automatically on access.

When a database-backed attribute of one of the objects is accessed, the object will be reloaded entirely from the database.

Parameters

obj

If passed, only mark the given object for autoreload. Otherwise, all cached objects will be marked for autoreload.

Set an object or all objects to be invalidated.

This prevents Storm from returning the cached object without first verifying that the object is still available in the database.

This should almost never be called by application code; it is only necessary if it is possible that an object has disappeared through some mechanism that Storm was unable to detect, like direct SQL statements within the current transaction that bypassed the ORM layer. The Store automatically invalidates all cached objects on transaction boundaries.

Explicitly specify the order of flushing two objects.

When the next database flush occurs, the order of data modification statements will be ensured.

Parameters	before	The object to flush first.
	after	The object to flush after before.

Cancel an explicit flush order specified with add_flush_order.

Parameters	before	The before object previously specified in a call to add_flush_order.
	after	The after object previously specified in a call to add_flush_order.

Flush all dirty objects in cache to database.

This method will first call the __storm_pre_flush__ hook of all dirty objects. If more objects become dirty as a result of executing code in the hooks, the hook is also called on them. The hook is only called once for each object.

It will then flush each dirty object to the database, that is, execute the SQL code to insert/delete/update them. After each object is flushed, the hook __storm_flushed__ is called on it, and if changes are made to the object it will get back to the dirty list, and be flushed again.

Note that Storm will flush objects for you automatically, so you'll only need to call this method explicitly in very rare cases where normal flushing times are insufficient, such as when you want to make sure a database trigger gets run at a particular time.

Block implicit flushes from operations like execute().

Unblock implicit flushes from operations like execute().

Return a {column: variable} dictionary suitable for inserts/updates.

Parameters	obj_info	ObjectInfo to inspect for changes.
	adding	If true, any defined variables will be considered a change and included in the returned map.

Fill missing values in variables of the given obj_info.

This method will verify which values are unset in obj_info, and set them to AutoReload, or if it's part of the primary key, query the database for the actual values.

Parameters	obj_info	ObjectInfo to have its values filled.
	primary_vars	Variables composing the primary key with up-to-date values (cached variables may be out-of-date when this method is called).
	result	If some value in the set of primary variables isn't defined, it must be retrieved from the database using database-dependent logic, which is provided by the backend in the result of the query which inserted the object.

Perform cache validation for the given obj_info.

Return object for obj_info, rebuilding it if it's dead.

Add an object to the set of known in-memory objects.

When an object is added to the set of known in-memory objects, the key is built from a copy of the current variables that are part of the primary key. This means that, when an object is retrieved from the database, these values may be used to get the cached object which is already in memory, even if it requested the primary key value to be changed. For that reason, when changes to the primary key are flushed, the alive object key should also be updated to reflect these changes.

In addition to tracking objects alive in memory, we have a strong reference cache which keeps a fixed number of last-used objects in-memory, to prevent further database access for recently fetched objects.

Remove an object from the cache.

This method is only called for objects that were explicitly deleted and flushed. Objects that are unused will get removed from the cache dictionary automatically by their weakref callbacks.

Resolve a variable set to a lazy value when it's touched.

This method is hooked into the obj_info to resolve variables set to lazy values when they're accessed. It will first flush the store, and then set all variables set to AutoReload to their database values.