[Grok-dev] Re: grok and the ORM of your choice

[Martijn Faassen]

Hey Brandon,

Some belated feedback to this.

 > Tim, after two or three days of playing with Grok - and very much
 > liking what I'm seeing - I have some database objects displaying in a
 > web page.  Since I'm very new at this, any of the steps below could be
 > the wrong approach; hopefully other list readers will point out better
 > techniques (and I will run off and rewrite using them!).  I'll happily
 > develop what follows into a tutorial once I've learned enough.

I think the steps you described are a good approach. There are 
potentially more advanced techniques of object relational mapping with 
container support that we could introduce, but your approach of using 
custom traversers is, I think, frequently just right.

If you're still interested, I'd be very happy if you could turn this 
into a tutorial so we can put it online!

Brandon Craig Rhodes wrote:

> My tiny application looks something like this:
> 
> 1) I am using SQL Alchemy to access the database. 

[snip]
> Then I hook the table up to SA:
> 
>       import sqlalchemy as sa
> 
>       engine = sa.create_engine('postgres://localhost/mage')
>       metadata = sa.DynamicMetaData('mymeta', threadlocal=False)
>       metadata.connect(engine)
> 
>       sa.mapper(Person, sa.Table('people', metadata, autoload=True))
> 
>    and I am up and running with a working Person object, whose
>    instances will now have an attribute for each column in the
>    database (like a Person has a .name and so forth).

I'm surprised you didn't need to integrate with Zope's transaction 
machinery, so that a commit automatically happens at the end of a 
request. There are two packages out there that do this for you:

z3c.zalchemy - I tried to use this but couldn't get it working for me.
z3c.sqlalchemy - this one worked for me in an experiment.

I really tried to make z3c.zalchemy work as I know Christian Theune 
worked on this (ZODB integration expert and one of the original Grok 
developers), but unfortunately I couldn't get it figured out for my use 
case.

[snip traversal]
> 
>    There is only one oddity here, and it probably indicates I don't
>    know enough about Grok/Zope 3 session management.

Aha! This may tie into my previous question. I'd be happy to help you 
get z3c.sqlalchemy set up to see whether that helps you.

[snip]

> 3) Once the Person or Account object has been reached by the URL,
>    there need to exist Views to render them for my customers using web
>    browsers.  Right now I just have an index page for each kind of
>    object, to which I give the name "index".  That name seems to be
>    special inside of Zope 3; while one can see an object by adding
>    "index" to the URL explicitly like ".../person/900010011/index", it
>    also appears to be the view that is used if no view name is added
>    to the end of the URL at all like "../person/900010011".  

Yes, this is in fact deliberate and intended. We may add a 
grok.default_view() directive to make this more clear.

[snip more good description]
>    I hesistate to bring up a few real issues I still have outstanding,
>    since the Grok developers themselves may well have stopped reading
>    by now; I can see their eyes glazing over as they had to read my
>    description of how one uses views!

We really need to get your tutorial in shape and up on grok.zope.org! It 
looks good and may be just what many people are looking for.

>    But in case people are still reading, my open issues are:
> 
>    - I am not yet totally free of the ZopeDB, because one last object,
>      the Application object itself, needs to be instantiated there!
>      My end goal is to have no ZopeDB, because the last thing I need
>      is another database to restore if I have to rebuild the app.
> 
>      But I have not yet figured out how to run a Grok application
>      without any ZopeDB whatsoever.

I'll skip any arguments in favor of a hybrid approach where the ZODB is 
used for things where it is most convenient (such as some forms of 
configuration) and a RDB for the cases where that is most convenient.

I heard at the post-EuroPython sprint that there is some work done on a 
hook in Zope 3 that allows you to run without ZODB. I don't know the 
details on this hook, but perhaps Philipp knows. Philipp?

>    - While users can access my Person and Account objects through the
>      web, I will sometimes want to access them through scripts.  While
>      the web is great for users clicking on single actions, I'm often
>      called upon to grant new email aliases to entire departments of
>      several hundred people at once.  I want to be able to write
>      normal Python scripts where I import my model and act upon it.
> 
>      But how does one use Grok objects "outside" of a running
>      instance?  I am mightily encouraged by PvW's recent posting
>      regarding "Death to Instances" involving Zope itself:
> 
>      http://www.z3lab.org/sections/blogs/philipp-weitershausen/2007_07_07_death-to-instances
> 
>      But I'm not yet savvy enough to know how this applies to Grok;
>      how do I write a script that imports and uses my Grok Models?

One thing you should try is:

bin/zopectl debug

You'll get a python prompt and 'root' is the name of the root object of 
Zope. You can get to your models from there, though if you want to get 
there by traversal I'll need to look up the right functionality.. (this 
is an argument in favor for special RDB backed container, in which case 
you could just get there using dictionary access)

Again, I hope you're still interested in pushing this further. I think 
having good relational database in Grok is very important and I'm happy 
to see someone is experimenting with it.

Regards,

Martijn