[Grok-dev] Re: megrok.rdb updated

[Toni Mueller]

Hi,

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

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

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

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

> (last time we looked at it we weren't able to retrieve the order  
> of definition for columns in a table, which is rather important to show  
> a nice form).

Reflection didn't work too well for me last I tried, since eg. the
database tables are often defined to have integer or string columns,
where in fact, a choice (one out of n elements, aka a set of radio
buttons, or a drop-down menu) would be appropriate, and/or is coded
into the application logic, imho.


Just my 0.02 cents worth of rants...

Kind regards,
--Toni++