[Grok-dev] schema.List returns a list, but is it persistent?

Sebastian Ware sebastian at urbantalk.se
Fri Aug 28 09:46:12 EDT 2009


I allways assumed applyData meant hands-off-storage-of-data-in-your- 
backend... I guess that was a misconception.

I'll have to look into creating a schema.PersistenList. I just wasn't  
aware that schema definitions were meant to be tightly coupled to the  
data storage. Just feels strange. Might stick to converting the list  
to PersistentList manually in the action handlers of edit and add  
forms, eventhough that too feels a bit odd.

Mvh Sebastian

On 28 aug 2009, at 13.47, Uli Fouquet wrote:

> Hi there,
>
> Sebastian Ware wrote:
>
>> Fair enough, this needs to be opt out or opt in. But it needs to be
>> there.
>>
>>   self.applyData(forceZodbDataTypes=True)
>
> I do not agree. applyData() is simply the wrong location to solve this
> problem. The function leaves it to the bound fields to determine the
> datatypes stored. This is the correct approach IMHO and should not be
> changed.
>
> Forcing a different datatype (possibly after a context object being
> created and already changed!) is not only horribly complicated
> introduces backward-compatibility problems, etc. , it also introduces
> black magic behind the scene. Worse, it would introduce unreliable
> magic: even with applyData changed you cannot be sure to have only
> PersistentLists in context objects because the list type used with a
> certain context object then depends on really having called  
> applyData()
> before. In other words, you would introduce even more subtle and more
> difficult to find error sources without getting rid of your problem
> completely.
>
> So, another -1.
>
>> As it works now there is a very real chance of data loss that hasn't
>> been mentioned anywhere in the documentation. And being a framework
>> that provides "sensible defaults" I think it is a bad idea to require
>> setting _p_changed = True in these cases. The chance of missing that
>> is huge and data loss is by far the worst thing that can happen. Even
>> worse if it is subtle and infrequent.
>
> This is a general problem of (naturally non-persistent) objects stored
> in ZODB, not only of schema lists and therefore would require a
> completely different approach, especially when it comes to people that
> want different backends than ZODB. Certainly nothing we would like to
> introduce before 1.0, would we?
>
> Concerning only schema lists you could simply define your own schema
> type with PersistentList as storage type and as already proposed by
> others here.
>
> Best regards,
>
> -- 
> Uli
>



More information about the Grok-dev mailing list