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

Leonardo Rochael Almeida leorochael at gmail.com
Wed Aug 26 17:11:58 EDT 2009


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.

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
>
>


More information about the Grok-dev mailing list