[Grok-dev] Re: STORM howto

[Laurence Rowe]

(wasn't sure what list I was being cc'ed into ;-)

Martin Aspeli wrote:

 > Martijn Faassen wrote:
 >
 >  > Cool to see so much work going on. Is one of those libraries just a
 >  > Python library that integrates schemas with SQLAlchemy, or is this all
 >  > mixed with other stuff?
 >
 >  I'm pretty sure collective.tin and collective.mercury are intended to be
 >  standalone. collective.rope, from what I understand, has Archetypes
 >  integration so maybe that's not so interesting.

collective.mercury takes the `transmutation` part of Alchemist for
creating zope schemas from sqlalchemy metadata and writes out the
schemas, collective.lead database definition and very basic model
(mapping) classes for a database. collective.mercury has no other
dependencies and is not required for runtime, it's just a convenience
tool. It may have grown some dependencies on the poorly named
z3schemabackports for certain types. z3schemabackports is currently a
collection of improvements that I need to role into the zope tree, but
haven't had the energy to push yet.

collective.tin does the heavy lifting. A hierarchy of objects is
rooted in a single TableFolder that lives in the ZODB. This contains
mapped objects of a certain type. These in turn may be TableSubFolders
and contain objects in a table linked with a foreign key. There is
also optional support for versioning and DCWorkflow.

It is split into a number of parts:

* A series of interfaces and adapters that provide zope container
interfaces for sqlalchemy backed data.

* Factories and `controller`s (mutators) for sqlalchemy mapped types.

* Add/Edit/Display form bases which call the factories and controllers

* Base classes that provide the CMF interface (mostly delegating to
adapter lookups)

* DCWorkflow support (which is leveraged to set permissions on mapped
objects fetched from the database).

It should be possible to make this work with Grok by just dropping the
base classes, though there is a bit of mess in utils.wrapsetup which
does some acquisition wrapping. This could maybe be turned into an
adapter so it becomes pluggable. The container part could possibly be
refactored to make use of sqlalchemy's custom container features.

There are currently no tests, though I should get round to writing
some over the next week (I'm moving database so now need them for my
peace of mind!). There is a start at some documentation here:
http://plone.org/documentation/tutorial/creating-sql-content-types-with-collective.tin


 >  collective.lead, as I said, is just about Zope transaction integration
 >  and about being able to say:
 >
 >   db = getUtility(IDatabase, name=u"mydb")
 >
 >  and then be able to execute SQLAlchemy ORM and SQL commands on that
 >  object. It should work in plain Zope 3 (it depends on zope.interface and
 >  ZODB3, from what I recall).

strictly zodb3 is not required, only transaction. The elro-tpc branch
will become 2.0 fairly soon. It pulls together some work done by
bitranch using scoped sessions and supporting the MyClass.query magic
and automatically associating new instances with sessions as well as
adding twophase and savepoint support. I just need to do a bit of
tidying up before I merge to trunk.

 >  I'm CC'ing Laurence who may have something to add.
 >
 >  Martin

Also, take a look at the new declaritive extension in SA 0.4.4. It
looks kind of cool, especially for the grok approach.

It'd be really nice to see collective.tin work with grok. I don't
think it should be too tricky to make it work.

Laurence