[Grok-dev] Re: STORM howto
faassen at startifact.com
Fri Mar 14 07:02:23 EDT 2008
Martin Aspeli wrote:
[snip Martin threatening to go use Pylons if we don't use SQLAlchemy :)]
> ... there are various SQLAlchemy-oriented
> solutions for Zope 2 and Plone (collective.lead, collective.tin,
> collective.mercury, collective.rope, z3c.sqlalchemy, z3c.zalchemy
> Alchemist and so on). I've never seen anyone use Storm with Plone (which
> of course doesn't mean that no-one does it).
> Perhaps this warrants some wider consultation before a decision is made?
No decision has been made yet. I'm not sure how to go about making this
decision - "wider consultation" sounds vague to me. Let's just think
about this carefully and experiment some more.
I think your post does show an important point: there is more momentum
*in the Zope community* behind SQLAlchemy than there is behind Storm.
With Storm, we have a bunch of big fish using it (Canonical, Lovely
systems). With SQLAlchemy, we have a lot of community activity. I think
that is an important point for SQLAlchemy. (of course that's not to say
there's no community activity for Storm at all - this thread is an
example of such after all!)
The other point that bothers me about Storm is that they do not have a
database schema abstraction in Python. It's not possible to generate a
RDB schema from Python. They do not generate "create table" statements
at all. Although they're not absolutely against adding such a feature,
instead, they prefer and recommend people maintain their RDB the RDB
way. While I agree that for many projects this is the right approach to
take, I also think that the lack of such can seriously hinder agility in
smaller/starting projects (where you just want to get going) and
"demo-ability". In addition, I think SQLAlchemy allows introspection of
existing databases, which allows for the generation of cool tools as
well. Again a schema abstraction is helpful to support this kind of feature.
Do you know whether people have done work integrating Zope 3 schema with
SQLAlchemy? I think we need a form of integration there, though I'm not
sure yet what shape this should take.
More information about the Grok-dev