[Grok-dev] Re: STORM howto
faassen at startifact.com
Sun Mar 16 15:05:46 EDT 2008
Thanks for participating in this discussion!
Laurence Rowe wrote:
> (wasn't sure what list I was being cc'ed into ;-)
> collective.mercury takes the `transmutation` part of Alchemist for
> creating zope schemas from sqlalchemy metadata and writes out the
You do generate the schemas in memory and then write them out? What
prompted the decision to write them out?
> 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 not sure what features you're referring to here; I'm not that
familiar with SQLAlchemy. Are scoped sessions and MyClass.query magic
both SQLAlchemy features? Would you recommend a new project starts with
Could you explain how collective.lead is better than z3c.sqlalchemy and
> Also, take a look at the new declaritive extension in SA 0.4.4. It
> looks kind of cool, especially for the grok approach.
Thanks for the hint. Is this part of SA 0.4.4?
> 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.
Okay, so far the heavy integration with Plone I saw in places of the
codebase worry me. Grok would only need a container type - I'm not sure
about the factories and we'd have to do a lot of integration work before
the form bases would be right for us. The workflow support and base
classes are not interesting. Given this integration and the state of the
tests you mention I'd be tempted to write something new, especially
given the amount of dis-integration with Plone that would need to be
done before collective.tin would be useful outside a Plone environment.
More information about the Grok-dev