[Grok-dev] Re: megrok.rdb updated

[Martijn Faassen]

Hey,

Toni Mueller wrote:
> On Wed, 25.06.2008 at 14:46:45 +0200, Martijn Faassen <faassen at startifact.com> wrote:
>> I've started updating megrok.rdb, using the recent work done on  
>> zope.sqlalchemy, z3c.saconfig, and my now somewhat greater understanding  
>> of SQLAlchemy.
> 
> attempting to write an SA-based Grok app, I would like to know at which
> point you think it's reasonable to start using the partially-updated
> rdbexample as a basis for a real-world project, instead of continuing
> the (so far working) collective.lead based approach for some time.
> Presently, I must say that I'd be completely unable to fix any errors I
> might encounter, and (as usual) am under a tight schedule. :/

It's hard to give an exact estimate of this, but I do plan on using this 
on a project I'm starting very soon, so I'll be hacking on it more.

>> * It turns out that using auto-generated primary keys as a container key  
>> doesn't look possible: this primary key is not assigned yet by the  
>> database by the time the container can be used.
> 
> I don't understand, but then, I didn't try the new model yet. Although
> recommended against by some, I keep using integers as primary keys,
> even if, or rather because, the model otherwise has no use for them.
> Which gives them "eternal life" as object identifiers, eg. because
> there'll be no need to change them.

Yes, I want to support this use case very much. There was a snag in 
supporting this, but Laurence Rowe had a few suggestions and I'm going 
to ask him at the grok sprint at EuroPython tomorrow, I think. :)

>> * More work needs to be done in making database setup easier. While  
>> z3c.saconfig helps a lot, it's still setting up quite a bit to get the  
>> basic case working.
> 
> The basic case would be to use one database over the whole lifetime of
> the application, right? That was quite easy to achive with the former
> version of the code, but then, I don't see how using more than one
> database with it even could be done, in case I wanted to.

Yes, the basic case is already pretty well covered, but there'd be some 
use in some more helpful classes and perhaps a bit of user interface even.

> What I'd _really_ like to see, but don't know how to implement, is a
> method to re-factor most code (schema and business logic) that accesses
> the database, into external libraries that I can use unaltered with and
> without Grok, with Grok providing not much more than one out of a
> number of UIs. Sort of
> 
> bundle-of-db-using-modules -------- Grok (one UI)
>                            \
> 			    \------ Command Line (one other UI)
> 			     \
> 			      \---- GTK-based client (yet another UI)
> 
> Of course, I'd still like to keep most of the auto-this and auto-that
> that Grok provides me with. ;)

megrok.rdb uses the SQLALchemy declarative extension. The idea of this 
is that you can design your model classes at the same time as the 
tables, in the same class, describing fields.

SQLAlchemy also supports another case where you define your tables and 
object-relational mappers in a less integrated way. It's more gluing up 
for the developer. We want to support this with megrok.rdb too, as a 
more or less fallback way of doing things. It'll be less nice, but at 
least your table definition code could be generic. I'm not sure whether 
it'd be possible to support reusing the mapper declarations themselves, 
as of course they talk about the concrete model object you want to map 
to, and that might be different in different applications.

That said, it might be possible to make megrok.rdb so lightweight it 
only depends on grokcore.component and not on full grok anymore. 
Currently that's not the case, but it's fairly close. It might be 
possible to go all the way. This should make reuse in even non-Zope 
settings easier. It's a fairly tough problem though, I expect.

>> * I haven't even touched the part that generates a Zope 3 schema from  
>> database schemas; this code is nice to generate forms. This requires  
>> some more study of the various alternatives around, and SQLAlchemy  
>> itself
> 
> I found that using the (older) rdb.Model as the basis for an
> auto-generated form, like in rdbexample, yields completely unusable
> results, with some fields omitted, and all other being 20-chars text
> input fields only.

Oh, yeah, that was definitely heavily prototyped code and it's still the 
same way. We need to really work out a better SQLAlchemy to Zope 3 
schema story. Hopefully we can still construct at least somewhat 
reasonable schemas for form generation, which you then probably always 
will have to tweak into *proper* schemas by supplementing information. 
My *hope* is that we can make this process clear enough and that it's 
not more work supplementing the information than just writing a new schema.

> Specifying a zope.schema in an interface by hand
> and defining the same attributes as SA's Column()s in the implementing
> rdb.Model-derived class, yields MUCH better results. But then, both are
> far from being "end-user-ready", at least in my case.

I'd like to hear more about what you think could be done to help making 
the separate schema + SA column story end-user ready.

Thanks for the feedback! This stuff is very valuable!

Regards,

Martijn