[Grok-dev] Re: Benefits of Grok -- please contribute
optilude at gmx.net
Tue May 15 16:32:40 EDT 2007
>> I would strongly advocate some deep thinking around how Grok
>> applications may want to interact with SQLAlchemy.
> Oh, it's been discussed from the very first Grok sprint, so it's
> definitely something we want to do. I know Christian was experimenting
> with mapping Zope 3 schemas to SQLAlchemy, but don't know how far that
> work got along.
>> This isn't so much about "you could do it" - there are an infinite
>> number of ways you could do it. It's about promoting some patterns, that
>> have been properly thought through and are known to work with the other
>> patterns people use in Grok.
> Exactly. That's what Grok should be about.
I like the idea of an "opinionated" framework, though I think Rails
maybe stole that one. ;-)
>> For example, let's say we had a catalog-like abstraction to search
>> metadata using an RDBMS. That'd allow very powerful query logic, even if
>> the real objects live in the ZODB.
> I think this one should be out of scope for a first cut, but something
> like that would of course be very cool.
I was just thinking out loud. It may not be that useful a use case for
most people. Databases have the annoying side-effect of requiring a
database server, running and available, and a username and password and
all that junk.
However, with the CA, we have a chance of making that kind of
abstraction work. It may be as much of an interesting use case to try it
out on, as an important feature to deliver.
>> Or, standard ways of registering traversal logic and views for
>> ORM-mapped things.
> This story should be in the first cut, I think, along with SQLAlchemy
> schema to Zope 3 schema mapping (and patterns for formlib use).
>> At the very least, there should be a well-supported (not necessarily in
>> the core) way of doing transaction integration. My collective.lead does
>> that for Zope 2, and I imagine the Zope 3 version isn't much different
>> (if at all?). It's very simple and low-level, though: I think Grok would
>> need to support slightly higher level abstractions.
> Can't we use one of the SQLAlchemy integration packages for Zope 3?
> There's two around. Would neither of them be suitable? I was hoping Grok
> could just use one of them.
Probably. I haven't looked at them. :)
One thing I'd advocate, is a separation of concerns between the package
or tool doing the low-level transaction integration and connector
set-up, and packages delivering higher level abstractions.
More information about the Grok-dev