[Grok-dev] Re: Benefits of Grok -- please contribute

[Martin Aspeli]

Hi Martijn,


>> 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.

Interesting!

>> 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).

Agreed.

>> 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.

Martin