[Grok-dev] Re: Grok and database generations

[Sebastian Ware]

Ok. I understand there are some pitfalls here. I have opted to add a  
"update_schema" method to my objects...

       def update_schema(self):
           try:
               if self.render_type is None:
                   self.render_type = 'table'
           except:
               self.render_type = 'table'

...and then a "sync" view to my application...

   class Sync(grok.View):
       grok.context(ProtonCMS)

       def update(self):
           theQuery = query.NotEq(('workflow_catalog',  
'object_type'), '')
           res = Query().searchResults(theQuery)
           for obj in res:
               obj.update_schema()
           return

       def render(self):
           print 'Sync done!'

This solves my problem with the least amount of extra code (I  
believe...).

Mvh Sebastian

4 sep 2007 kl. 19.47 skrev Leonardo Rochael Almeida:

> Just be careful not to set mutable attributes in the class like this,
> otherwise when you mutate the attribute, you'll be mutating an
> attribute instance shared by the class with all instances.
>
> You might also consider using properties for very tricky cases (e.g.
> the mutable attribute case above), consulting an internal variable
> that defaults to None and setting it to something else on first
> access, which is a common idiom in OO languages.
>
> Cheers, Leo
>
> On 9/4/07, Sebastian Ware <sebastian at urbantalk.se> wrote:
>> Excellent!
>>
>> I set my default attributes in the __init__ even when they aren't
>> passed during instansiation. Adding them as class attributes sounds
>> like a much better solution! This pattern would be great to use in
>> sample apps.
>>
>> I agree, this is solution covers my usecase just fine. Further down
>> the line, maybe an import/export component would be useful. :)
>>
>> Mvh Sebastian
>>
>>
>> 4 sep 2007 kl. 18.40 skrev Philipp von Weitershausen:
>>
>>> Sebastian Ware wrote:
>>>> I have been looking at the zope.app.generations package. For those
>>>> who don't know about it, generations keeps track on your objects.
>>>> The generations schema manager allows you to execute an evolve
>>>> method in order to update objects to a required level of
>>>> functionality. To determine which objects to update ituses a  
>>>> counter.
>>>> However, my most usual use case is that I have added some new
>>>> default values to the __init__ method of a class and I want to
>>>> update all the objects of that class to reflect this change. But I
>>>> want to do this without having to write any extra code. I just
>>>> want to sync my objects...
>>>> Is there any simple and smart way I could do this?
>>>
>>> Yup. It's called class attributes. When an instance doesn't have a
>>> particular attribute, but a class does, the class attribute will be
>>> used. When overwritten, it will be done so on the instance. For
>>> example::
>>>
>>>   class Foo(object):
>>>
>>>       # make sure old instances also get this attribute
>>>       attr = default_value_for_old_instances
>>>
>>>       def __init__(self, attr=some_default):
>>>           self.attr = attr
>>>
>>> So if you have an instance of 'Foo' that was created before
>>> __init__ set the 'attr' attribute, it will now be possible to say
>>> 'foo_instance.attr' and it will resolve to
>>> 'default_value_for_old_instances'.
>>>
>>>> If not, would this not be an excellent feature to add to Grok?
>>>
>>> For simple cases, I think defensive programming (e.g. gracefully
>>> handling the absence of attributes) and tricks like I've shown
>>> above work well enough that we don't need something special in Grok.
>>>
>>> *If* we have to introduce something to Grok, then it'll likely have
>>> to handle trickier things as well. But tricky things are hard to do
>>> in-place. They usually require good understanding of the way the
>>> ZODB works. I think 'dump and reload' is much easier when you have
>>> massive and/or tricky refactorings going on. As Tres says, it's not
>>> a surprise that pretty much all RDBMS do it this way.
>>>
>>>
>>> --
>>> http://worldcookery.com -- Professional Zope documentation and
>>> training
>>
>> _______________________________________________
>> Grok-dev mailing list
>> Grok-dev at zope.org
>> http://mail.zope.org/mailman/listinfo/grok-dev
>>