[Checkins] SVN: z3c.sqlalchemy/trunk/ reorg
Andreas Jung
andreas at andreas-jung.com
Sat Mar 15 09:13:00 EDT 2008
Log message for revision 84660:
reorg
Changed:
A z3c.sqlalchemy/trunk/CHANGES.txt
A z3c.sqlalchemy/trunk/README.txt
U z3c.sqlalchemy/trunk/setup.py
D z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/CHANGES.txt
D z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/README.txt
D z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/version.txt
-=-
Copied: z3c.sqlalchemy/trunk/CHANGES.txt (from rev 84658, z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/CHANGES.txt)
===================================================================
--- z3c.sqlalchemy/trunk/CHANGES.txt (rev 0)
+++ z3c.sqlalchemy/trunk/CHANGES.txt 2008-03-15 13:13:00 UTC (rev 84660)
@@ -0,0 +1,285 @@
+1.1.3 (20.02.2008)
+-------------------
+
+ - another savepoint fix
+
+ - fixed regression error introduced by previous change: commit the
+ zope transaction when ready in tpc_finish [maurits]
+
+ - fixed issue where session's transaction.nested was being called as
+ a callable (it should be straight attribute access) [Rocky]
+
+
+1.1.2 (16.02.2008)
+-------------------
+
+ - fixed ZODB savepoint implementation. Now returning a proper dummy
+ savepoint
+
+1.1.1 (13.02.2008)
+-------------------
+
+ - the SessionDataManager now supports ZODB savepoints
+
+1.1.0 (17.01.2008)
+-------------------
+
+ - WARNING: this version requires SA 0.4.X and higher
+
+ - fixed import issues with the upcoming SA 0.4.X series
+
+ - create_session() calls (for SA 0.4.X)
+
+ - the unittests support an optional $TEST_DSN environment in order
+ to run the test against an existing database (other than SQLite)
+
+ - major overhoul of the Zope transaction integration: now using
+ one DataManager for the session object and the connection. The
+ connection as returned through the 'connection' property is also
+ used for creating a new 'session'. Older z3c.sqlalchemy version
+ used separate connections. This allows applications to use both
+ a session and a connection within the same Zope request/thread
+ without running into transaction problems. SQL actions and
+ session related modifications should happen within the same
+ transaction.
+
+ - Wrapper constructor now accepts two new optional dicts
+ 'engine_options' and 'session_options' that will be passed down
+ to the engine and the sessionmaker. Patch provided by
+ Klaus Barthelmann.
+
+ - mapped objects now provide a method asDict() to return the values
+ of an objects as dict.
+
+
+1.0.11 (30.07.2007)
+-------------------
+
+ - replaced BoundMetaData() with MetaData() (requires SA 0.3.9+)
+
+ - removed zope.* dependencies in order to avoid zope.* version
+ mismatches for now
+
+
+1.0.10 (16.07.2007)
+-------------------
+
+ - using Zope 3.3.X as a fixed depenceny
+
+
+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 keyword
+ 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
Copied: z3c.sqlalchemy/trunk/README.txt (from rev 84658, z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/README.txt)
===================================================================
--- z3c.sqlalchemy/trunk/README.txt (rev 0)
+++ z3c.sqlalchemy/trunk/README.txt 2008-03-15 13:13:00 UTC (rev 84660)
@@ -0,0 +1,205 @@
+=====================================================
+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.4.0 or higher (no support for SQLAlchemy 0.3)
+- Python 2.4+
+
+
+Installation:
+=============
+
+Either using easy_install::
+
+ easy_install z3c.sqlalchemy
+
+or using Python directly::
+
+ python2.4 setup.py install
+
+Note:
+-----
+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')
+
+
+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.
+
Modified: z3c.sqlalchemy/trunk/setup.py
===================================================================
--- z3c.sqlalchemy/trunk/setup.py 2008-03-15 13:11:47 UTC (rev 84659)
+++ z3c.sqlalchemy/trunk/setup.py 2008-03-15 13:13:00 UTC (rev 84660)
@@ -23,15 +23,11 @@
'Topic :: Software Development :: Libraries :: Python Modules',
]
-version_file = os.path.join('src', 'z3c', 'sqlalchemy', 'version.txt')
-version = open(version_file).read().strip()
+version = '1.1.14'
-readme_file = os.path.join('src', 'z3c', 'sqlalchemy', 'README.txt')
-desc = open(readme_file).read().strip()
+desc = open('README.txt').read().strip()
+changes = open('CHANGES.txt').read().strip()
-changes_file = os.path.join('src', 'z3c', 'sqlalchemy', 'CHANGES.txt')
-changes = open(changes_file).read().strip()
-
long_description = desc + '\n\nChanges\n=======\n\n' + changes
Deleted: z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/CHANGES.txt
===================================================================
--- z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/CHANGES.txt 2008-03-15 13:11:47 UTC (rev 84659)
+++ z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/CHANGES.txt 2008-03-15 13:13:00 UTC (rev 84660)
@@ -1,285 +0,0 @@
-1.1.3 (20.02.2008)
--------------------
-
- - another savepoint fix
-
- - fixed regression error introduced by previous change: commit the
- zope transaction when ready in tpc_finish [maurits]
-
- - fixed issue where session's transaction.nested was being called as
- a callable (it should be straight attribute access) [Rocky]
-
-
-1.1.2 (16.02.2008)
--------------------
-
- - fixed ZODB savepoint implementation. Now returning a proper dummy
- savepoint
-
-1.1.1 (13.02.2008)
--------------------
-
- - the SessionDataManager now supports ZODB savepoints
-
-1.1.0 (17.01.2008)
--------------------
-
- - WARNING: this version requires SA 0.4.X and higher
-
- - fixed import issues with the upcoming SA 0.4.X series
-
- - create_session() calls (for SA 0.4.X)
-
- - the unittests support an optional $TEST_DSN environment in order
- to run the test against an existing database (other than SQLite)
-
- - major overhoul of the Zope transaction integration: now using
- one DataManager for the session object and the connection. The
- connection as returned through the 'connection' property is also
- used for creating a new 'session'. Older z3c.sqlalchemy version
- used separate connections. This allows applications to use both
- a session and a connection within the same Zope request/thread
- without running into transaction problems. SQL actions and
- session related modifications should happen within the same
- transaction.
-
- - Wrapper constructor now accepts two new optional dicts
- 'engine_options' and 'session_options' that will be passed down
- to the engine and the sessionmaker. Patch provided by
- Klaus Barthelmann.
-
- - mapped objects now provide a method asDict() to return the values
- of an objects as dict.
-
-
-1.0.11 (30.07.2007)
--------------------
-
- - replaced BoundMetaData() with MetaData() (requires SA 0.3.9+)
-
- - removed zope.* dependencies in order to avoid zope.* version
- mismatches for now
-
-
-1.0.10 (16.07.2007)
--------------------
-
- - using Zope 3.3.X as a fixed depenceny
-
-
-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 keyword
- 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
Deleted: z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/README.txt
===================================================================
--- z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/README.txt 2008-03-15 13:11:47 UTC (rev 84659)
+++ z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/README.txt 2008-03-15 13:13:00 UTC (rev 84660)
@@ -1,205 +0,0 @@
-=====================================================
-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.4.0 or higher (no support for SQLAlchemy 0.3)
-- Python 2.4+
-
-
-Installation:
-=============
-
-Either using easy_install::
-
- easy_install z3c.sqlalchemy
-
-or using Python directly::
-
- python2.4 setup.py install
-
-Note:
------
-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')
-
-
-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.
-
Deleted: z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/version.txt
===================================================================
--- z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/version.txt 2008-03-15 13:11:47 UTC (rev 84659)
+++ z3c.sqlalchemy/trunk/src/z3c/sqlalchemy/version.txt 2008-03-15 13:13:00 UTC (rev 84660)
@@ -1 +0,0 @@
-1.1.3
More information about the Checkins
mailing list