z3c.sqlalchemy 1.0.13

A SQLAlchemy wrapper for Zope 2 and Zope 3

=====================================================
z3c.sqlalchemy - A SQLAlchemy wrapper for Python/Zope
=====================================================


What is z3c.sqlalchemy?
=======================

z3c.sqlalchemy is yet another wrapper around SQLAlchemy. The functionality of
the wrapper is basically focused on easy integration with Zope 2 and Zope 3.
The wrapper cares about connection handling, optional transaction integration
with Zope 2/3 and wrapper management (caching, introspection). z3c.sqlalchemy
gives you flexible control over the mapper creation. Mapper classes can be

- auto-generated (with or without autodetection of table relationships)

- configured by the developer


What z3c.sqlalchemy does not do and won't do:
=============================================

- no support for Zope 3 schemas

- no support for Archetypes schemas


z3c.sqlachemy just tries to provide you with the basic functionalities you need
to write SQLAlchemy-based applications with Zope 2/3. Higher-level
functionalities like integration with Archetypes/Zope 3 schemas are subject to
higher-level frameworks. z3c.sqlalchemy does not address these frameworks.


Requirements:
=============

- Zope 2.8+, Zope 3.X

- SQLAlchemy 0.3.8 or higher

- Python 2.4+


Installation:
=============

- using easy_install::

> easy_install z3c.sqlalchemy

Use the --no-deps option if you don't want the zope.* eggs installed


- using Python directly::

> python2.4 setup.py install

(or using python2.5)


- z3c.sqlalchemy depends on the modules zope.component, zope.schema
and zope.interface. If you are using z3c.sqlalchemy in a Python-only
environment, ensure the these components have to be installed either
as eggs or by setting the PYTHONPATH to a corresponding Zope 2
or Zope 3 installation.


Usage
=====

Basic usage from within a pure Python application::

> from z3c.sqlalchemy import createSAWrapper
> wrapper = createSAWrapper('postgres://postgres:postgres@host/someDB')
> session = wrapper.session
> FormatMapper = wrapper.getMapper('format') # auto-generated mapper for table 'format'
> for row in session.query(FormatMapper).select(...): print row
> session.flush() # if necessary

When using Zope 2/3 you can use the same code but you want a wrapper that
participates in Zope transactions. For this purpose you must use the additional
parameter 'forZope'::

> from z3c.sqlalchemy import createSAWrapper
> wrapper = createSAWrapper('postgres://postgres:postgres@host/someDB', forZope=True)
> session = wrapper.session

In this case the session will participate automatically in a Zope transaction.
The wrapper will call automatically session.flush() upon a transaction commit.
Please note that 'wrapper.session' will always return the same session instance
within the same transaction and same thread.

For a real-world application you don't want to create a new wrapper for every
new request. Instead you want to register a wrapper instance as named utility
(ISQLAlchemyWrapper) and lookup up the wrapper (the utility!) by name from
within your application. This approach is very similiar to looking up an
databases adapter or a ZSQL method through acquisition.


By default "wrapper.getMapper(name)" will always auto-generate a new mapper
class by using SQLAlchemy auto-load feature. The drawback of this approach is
that the mapper class does not know about relationships to other tables. Assume
we have a one-to-many relationship between table A and B and you want
z3c.sqlalchemy to generate a mapper that is aware of this relationship. For
this purpose you can create a wrapper with a "model" as optional parameter. A
model is basically a configuration or a series of hints in order to tell
z3c.sqlalchemy how mappers a generated.

Example::

> from z3c.sqlalchemy import createSAWrapper, Model
> model = Model()
> model.add(name='A', relations=('B',))
> wrapper = createSAWrapper('postgres://postgres:postgres@host/someDB', model=model)
> AMapper= wrapper.getMapper('A')

This will generate a mapper AMapper where all instances of AMapper have a
property 'B' that relates to all corresponding rows in B (see the SQLAlchemy
documentation on mappers, properties and relation()). In this example you
define the relationship between A and B explictly through the 'relations'
parameter (as a sequence of related table names).

z3c.sqlalchemy also supports the auto-detection of relationships between tables.
Unfortunately SQLAlchemy does not support this feature out-of-the-box and in a portable
way. Therefore this feature of z3c.sqlalchemy is highly experimental and currently
only available for Postgres (tested with Postgres 8.X).::

> from z3c.sqlalchemy import createSAWrapper, Model
> model = Model()
> model.add(name='A', autodetect_relations=True)
> wrapper = createSAWrapper('postgres://postgres:postgres@host/someDB', model=model)
> AMapper= wrapper.getMapper('A')

In this case z3c.sqlalchemy will scan all tables in order to detect
relationships automatically and build the mapper class and its properties
according to the found relationships. Warning: this feature is experimental and
it might take some time to scan all tables before the first request. Currently
only Postgres tables in the 'public' schema are supported).

In same cases you might be interested to use your own base classes for a
generated mapper. Also this usecase is supported by passing the base class to
the model using the 'mapper_class' parameter::

> from z3c.sqlalchemy import createSAWrapper, Model
> from z3c.sqlalchemy.mapper import MappedClassBase
> class MyAMapper(MappedClassBase): pass
> model = Model()
> model.add(name='A', relations=('B',) mapper_class = MyAMapper)
> wrapper = createSAWrapper('postgres://postgres:postgres@host/someDB', model=model)
> AMapper= wrapper.getMapper('A') # AMapper will be an instance of MyAMapper

When you are working with wrapper in a Zope 2/3 environment you are usually
interested to to register a wrapper instance as named utility implementing
ISQLAlchemyWrapper. You can can perform the registration lazily by passing the
name utility as 'name' parameter to the createSAWrapper(...,
name='my.postgres.test.db') method.

A convenience method for obtaining a wrapper instance by name is available
through getSAWrapper::

> createSAWrapper(dsn,..., name='my.name')
> ...
> wrapper = getSAWrapper('my.name')


Installation:
=============

- either install z3c.sqlalchemy using easy_install from Cheeseshop:

**easy_install z3c.sqlalchemy**

- or download the sources from Cheeseshop at

http://cheeseshop.python.org/pypi/z3c.sqlalchemy/1.0.0

and install it manually after unpacking the sources:

**python2.4 setup.py install**


Supported systems
=================

z3c.sqlalchemy was developed with Zope 2.8/Zope 3.0 and basically tested against
Postgres 7.4.X and 8.X and SQLite 3.3.


Known issues
============

Running z3c.sqalchemy against MySQL databases without transaction support might
cause trouble upon the implicit commit() operation. For this reason MySQL without
transaction support isn't supported right now


Author
======

z3c.sqlalchemy was written by Andreas Jung for Haufe Mediengruppe, Freiburg, Germany
and ZOPYX Ltd. & Co. KG, Tuebingen, Germany.


License
=======

z3c.sqlalchemy is licensed under the Zope Public License 2.1.

See LICENSE.txt.


Contact
=======

| ZOPYX Ltd. & Co. KG
| Andreas Jung
| Charlottenstr. 37/1
| D-72070 Tuebingen, Germany
| E-mail: info at zopyx dot com
| Web: http://www.zopyx.com


Credits
=======

Parts of the code are influenced by z3c.zalchemy (Juergen Kartnaller, Michael
Bernstein & others) and Alchemist/ore.alchemist (Kapil Thangavelu). Thanks to
Martin Aspeli for giving valuable feedback.



Changes:
========

<<<<<<< .mine
1.0.12 (08.07.2007)

- restored missing 1.0 branch

=======
1.0.13 (05.06.2008)

- fix in transaction integration

1.0.12 (08.07.2007)

- restored missing 1.0 branch

>>>>>>> .r87177
1.0.9 (08.07.2007)

- added namespace declarations

- reST-ified documentation


1.0.8 (28.06.2007)

- SessionDataManager: create a session transaction as late
as possible and only if necessary in order to minimize deadlocks.
So z3c.sqlalchemy won't create a transaction any more if there
only SELECT operations within the current session.


1.0.7 (27.06.2007)

- SessionDataManager: moved commit code from tpc_vote()
to tpc_finish() (Thanks to Christian Theune for the hint)

1.0.6 (25.06.2007)

- added 'namespace_packages' directive to setup.py

- cache 'metadata' property

1.0.5 (13.06.2007)

- It should be now safe to use sessions from multiple wrappers
within one Zope transaction. In former versions of z3c.sqlalchemy
calling wrapper1.session and wrapper2.session within the same
transaction would return a session bound to wrapper1 in both
cases.

1.0.4 (09.06.2007)

- added new 'transactional' flag (used by SQLAlchemyDA only)

1.0.3 (26.05.2007)

- new 'cascade' parameter for the Model.add()

- tweaked the ZODB transaction integration a bit

1.0.2 (13.05.2007)

- MappedClassBase has a new convinience method getMapper() that returns a
mapper class associated through a relation with the current mapper


1.0.1 (unreleased)

- MappedClassBase: new clone() method

- more checks in Model.add()


1.0.0 (05.05.2007)

- source code polishing

- documentation update


0.1.13 (05.05.2007)

- sessions were returned from the wrong cache

- moved the rollback/commit handling inside the SessionDataManager
in order to play more nicely with the TPC. See
http://mail.zope.org/pipermail/zodb-dev/2007-May/010996.html


0.1.12 (03.05.2007)

- createSAWrapper() got a new optional 'name' parameter in order
to register the wrapper automatically instead of using a dedicated
registerSAWrapper(wrapper, name) call

0.1.11 (02.05.2007)

- added check for the 'mapper_class' attribute (classes from now
on must be a subclass of MapperClassBase)

- a Zope-aware SAWrapper now has a 'connection' property that can
be used to execute SQL statements directly. 'connection' is an
instance of sqlalchemy.Connection and directly tied to the current
Zope transaction.

- changed the caching of the connection and session object for Zope wrapper
since the id of a transaction is not reliable (different transaction
object can re-use the same memory address leading to cache errors)


0.1.10 (30.04.2007)

- fixed a bug in mapper (unfortunately I forgot to commit a
necessary change)

- removed the 'primary_key' parameter introduced in 0.1.9 because
we don't need. It can be defined within the model using a
PrimaryKeyConstraint()

- createSAWrapper: setting forZope=True for a non-postgres DSN
now also returns a Zope-aware wrapper instance (instead
of a BaseWrapper instance). (Reported by Martin Aspeli)


0.1.9 (26.04.2007)

- base.py: the 'model' parameter can now also be a callable
returning an instance of model.Model

- base.py: calling a model provider or a method providing a
model with a BoundMetaData instance in order to allow
table auto-loading

- Model.add() got a new parameter 'primary_key' in order to specify a
primary_key hint. This is useful when you are trying to auto-load a view
as Table() having no primary key information. The 'primary_key' parameter is
either None or a sequence of column names.


0.1.8 (23.04.2007)

- added shorter method names as aliases

- don't generate a new mapper class if a custom mapper
class is defined within the model


0.1.7 (21.04.2007)

- replaced 'echo' parameter of the constructor with a generic **kw
parameter in order to provide full parameter support for
create_engine. Optional arguments passed to the constructur are
passed directly to create_engine()

- fixed the documentation a bit

- added registerMapper() to BaseWrapper class

- registerSQLAlchemyWrapper() now defers the registration until
the Wrapper is used first when calling getSQLAlchemyWrapper()

- the 'name' parameter of Model.add() now supports schemas (if
available). E.g. when using Postgres you can reference as
table within a different schema through '<schema>.<tablename>'.

- Model.add() accepts a new optional parameter 'table_name' that
can be used to specify the name of a table (including schema
information) when you want to use the 'name' parameter as
an alias for the related table/mapper.


0.1.6 (28.03.2007)

- fixed a bug in registerSQLAlchemyWrapper

0.1.5 (28.03.2007)

- registerSQLAlchemyWrapper() should now work with Zope 2.8-2.10

- abort() was defined twice inside the DataManager class

0.1.4 (21.03.2007)

- the Model class now behave (where needed) as a sorted
dictionary. Its items() method must returned all items
in insertion order.

0.1.3 (20.03.2007)

- added getMappers() convenience method

- the Zope wrapper uses SessionTransactions in order to be able
to flush() as session with a transaction in order to read
row previously inserted within the same transaction


0.1.2 (unreleased)

- fixed class hierarchy issues with Postgres wrapper classes


0.1.1 (unreleased)

- fixed setup.py

0.1 (18.03.2007)

- initial version