[Grok-dev] Re: Grok ORM with Storm

[Martijn Faassen]

Hey,

This is some feedback; note that I have no actual experience using Storm 
yet so I might be wrong about some things.

In general we try to use a combination of grokkable base classes and 
grok directives on those classes to set meta information.

Christian Klinger wrote:
[snip]
> 
> 1. SMASH ZCML
> --------------
> 
> In the package zope.storm it´s necesarry to define a store in zcml.
> I think we can SMASH this zcml-slug.
> 
>   <store name="contact" uri="sqlite:/tmp/contact.db"/>

Yes, I imagine we can turn this into something like:

class MyStore(megrok.storm.Store):
    grok.name('contact')
    grok.uri('sqlite:/tmp/contact.db')

This would introduce a new grok.uri directive. I don't know whether this 
would have a lot of other uses. Perhaps 
megrok.storm.connectionid('sqlite:/tmp/contact.db') instead.

> 2. Make the grok config in our grok.Model easier:
> -------------------------------------------------
> 
> This is the example Model of the Howto [2]:
> 
>   class Contact(grok.Model, Storm):
>       grok.implements(IContact)
>       __storm_table__ = "Contacts"
> 
>       id = Int(primary=True)
>       name = Unicode()
>       city = Unicode()
> 
> Maybe we can do something like megrok.storm.StormTable('Contacts') 
> instead of __storm_table__ = Contacts.

I think we might want to avoid subclassing grok.Model directly. Instead 
we'd need a way for the system to recognize models which are *not* 
subclasses of grok.Model as models. Then we could do:

This looks like a directive, so:

class Contact(megrok.storm.Model):
     grok.implements(IContact)
     megrok.storm.table('Contacts')

     id = Int(primary=True)
     name = Unicode()
     city = Unicode()

Alternatively we could even import Storm directly from Storm and write a 
grokker for them. It could recognize the megrok.storm.table() annotation 
and then stuff it in as __storm_table__.

> 3. The container config:
> ------------------------
> 
> This is the config of the Container in the Howto [2]:
> 
>   class contacts(StormContainer, grok.Application, grok.Container):
>       """ this application inherits from StormContainer too """
>       def __init__(self):
>           super(contacts, self).__init__()
>           self.setClassName('contacts.contact.Contact')
>           self.setStoreUtilityName('contact')
> 
> Maybe it´s possible to say megrok.storm.setClassName('xxx') and 
> megrok.storm.setStoreUtiltiyName('xxx')

I think grok.Container shouldn't be a mix-in here. Again we should have 
a system that can recognize grok.Container as a kind of model.

what about this?

from contacts.contact import Contact

class Contacts(megrok.storm.Container):
   megrok.storm.content(Contact) # or content_class, perhaps?

I don't know what setStoreUtilityName() does exactly, but we could use a 
similar directive:

   megrok.storm.storage('contact')

where 'contact' is the utility name. Why does the storm container need 
to know the storage but the storm model does not?

I think these can be set before the __init__() is called on the 
class-level, right? Or is there any reason for thesse settings to be 
dynamic?

> So i think i have to work on megrok.storm package which includes
> these simplifications.

Great!

> Please give me some feedback.

There you are. I tried to give some feedback to make the storm stuff 
more grok-like. Hopefully I'm not saying impossible things.

> 
> [1]http://stormcontainer.googlecode.com/svn/trunk/src/stormcontainer/
> [2]http://plone.grok.quintagroup.com/documentation/how-to/grok-orm-with-storm

You didn't publish the second link. I published it for you, I hope you 
don't mind.

Regards,

Martijn