[Grok-dev] megrok.rdb feedback

[Martijn Faassen]

Hey,

Lennart Regebro wrote:
> The main problem was that the documentation is a bit lacking

Yeah, a from-scratch document needs to be written.

> Also, the documentation focuses on a slightly complex example with one
> container which is not a model, and two models who are not containers,
> but has a relationship. 

I'm not sure I get it. All containers *are* models in Grok. It's just 
that rdb.Container nor rdb.QueryContainer are not rdb.Model, but more 
like grok.Model. A model is information mapped from a table. A container 
is a relationship mapped into an object.

> This possible makes sense if you come from the
> SQL world, but to a Zopista that is a quite complicated example to
> start with. This caused me a lot of head scratching when I wanted a
> Folder-type, until I realized I should not use Container, but
> QueryContainer + Model as a base class to make a Folder. 

What is a 'Folder-type'?

The idea is that generally your RDB app consists of rdb.Model linked 
together with relations, represented as a rdb.Container. You use 
grok.traversable to make those relations be exposed to the web.

This leaves the starting point however - you need to be able to get to a 
model before you can get to containers. This is why there is also 
rdb.QueryContainer, which allows you to create a container that 
represents a query and is not backed by a relation in the database. This 
way you can get to your initial models. rdb.QueryContainer is also 
useful to build query-backed object structures that the ORM doesn't let 
you create. Both rdb.Container and rdb.QueryContainer make sure that 
URLs can be generated to the objects inside them.

> So probably,
> the example application could be extended with a second module with
> that type of example, unless it simply is not a good idea, for reasons
> that I'm not aware of. (I'm probably not gonna make any folders
> anyway, but it seemed like a good, simple example, but there was only
> the more complicated example with a relation in the docs).

I'd like to see you create a separate relational database example, 
independent from the first example. This keeps the concerns separate.

> Setting up the database seems to consist of a bunch of steps that need
> to be done in a specific order. Possibly this can be simplified
> somehow, by putting these steps into one step.

There are some options in setting up a database - there's support in 
z3c.saconfig for locally defined database sessions but rdbexample sets 
up a global one. See also z3c.saconfig, which hopefully explains this a 
bit better.

> I liked that there are field types so that making a model is dead
> easy. Once I figured out why my database tables didn't get created it
> was pretty much plain sailing.

rdb.setupDatabase will create your database tables for you (or do 
reflection, depending on how you set up your rdb.Model subclasses).

> What I haven't looked at yet is to get rid of the ZODB completely,

Haven't looked at that either.

> nor how to make containers that can take some sort of generic content,  so
> you can have many models in one container. 

Haven't looked at that either. SQLAlchemy has all kinds of advanced 
support that ought to help here.

Regards,

Martijn