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

[Gary Poster]

On Aug 26, 2009, at 5:11 PM, Leonardo Rochael Almeida wrote:

> IMHO, for form uses inside standard Grok, storing a list (or a
> PersistentList) shouldn't be much trouble, since only a really badly
> designed form would actually bother to contain so much data in a value
> returned from a schema.List element as to make little difference
> regarding performance.
>
> Personally I'd be +0 at leaving things as they are (and +1 for leaving
> it as is at least for Grok 1.0), +0.5 for having grok replace it with
> a PersistentList if the interface or the implementation is not all
> that complicated and -1 for adding a dependency on zc.blist for this
> use-case.

Makes sense to me, FWIW.

Gary

>
> Alternatively we might push zope.schema.List (or rather it's Iterable
> superclass) into accepting a iterable_type keyword argument which
> people could then set to whatever they want in their own code.
>
> Cheers, Leo
>
> On Wed, Aug 26, 2009 at 17:55, Gary Poster<gary.poster at gmail.com>  
> wrote:
>> It's actually even more subtle that this.
>>
>> For the ZODB, PersistentList is OK if you are storing a relatively  
>> small
>> number of Persistent objects, or a relatively small number of  
>> relatively
>> small pickle-able objects.  But if you are storing a lot of  
>> objects, or a
>> medium number of very large pickle-able objects like strings, and  
>> you are
>> going to mutate the list, the PersistentList has bad performance
>> characteristics.  zc.blist attempts to solve the problem in that  
>> case, for
>> instance.
>>
>> While I agree that this is a gotcha, I don't see a good answer for  
>> it.
>>  Under the circumstances, zope.schema.List should probably return a  
>> list.
>>  Maybe grok itself, with its goals, if it is "opinionated" in favor  
>> of the
>> ZODB, can make a grok.schema subclass that "does the right thing"  
>> from
>> grok's perspective.
>>
>> Gary
>>
>> On Aug 26, 2009, at 12:26 PM, Sebastian Ware wrote:
>>
>>> I eventually realised that :) but I do think it is a bug in  
>>> applyData,
>>> since you would really expect applyData to return automatically
>>> persistent data types (at least as default). Right now it is kind of
>>> "it just works... most of the time...".
>>>
>>> Mvh Sebastian
>>>
>>> On 26 aug 2009, at 18.13, Leonardo Rochael Almeida wrote:
>>>
>>>> On Wed, Aug 26, 2009 at 12:25, Leonardo Rochael
>>>> Almeida<leorochael at gmail.com> wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>> On the other hand, it's very easy to create your own class that
>>>>> extends from schema.List to return your own datatype. IIRC you  
>>>>> only
>>>>> have to override one attribute in the subclass, and it will  
>>>>> receive
>>>>> the same widgets as the superclass unless you register  
>>>>> differently or
>>>>> alter the implemented interfaces.
>>>>
>>>> The attribute is _type, btw. The reason PersistentList is not the
>>>> default is because zope.schema doesn't assume you're going to use  
>>>> it
>>>> with zodb.
>>>>
>>>> Cheers, Leo
>>>>
>>>>>
>>>>> Cheers, Leo
>>>>>
>>>>> On Wed, Aug 26, 2009 at 11:56, Sebastian
>>>>> Ware<sebastian at urbantalk.se> wrote:
>>>>>>
>>>>>> Lists need to be implemented as PersistentList in order to be
>>>>>> automatically persisted to ZODB, however schema.List returns an
>>>>>> ordinary list and applyData seemingly stores this list as is.  
>>>>>> Isn't
>>>>>> this a big problem?
>>>>>>
>>>>>>   tags = schema.List(title=u"Content Tags",
>>>>>> value_type=schema.Choice(title=u"Content Tag",
>>>>>>          vocabulary='Content Tags'), default = [])
>>>>>>
>>>>>> Mvh Sebastian
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Grok-dev mailing list
>>>>>> Grok-dev at zope.org
>>>>>> http://mail.zope.org/mailman/listinfo/grok-dev
>>>>>>
>>>>>
>>>
>>> _______________________________________________
>>> Grok-dev mailing list
>>> Grok-dev at zope.org
>>> http://mail.zope.org/mailman/listinfo/grok-dev
>>
>>