Change of behaviour in couchdbkit gitmaster unexpected

[Joan Touzet]

Hi there,

Prior to the current code in the couchdbkit git master, if I created a
schema with a ListProperty(required=True), I could save an empty list
[] and couchdbkit would pass it. Now, if required=True, this is
invalid.

There is also a regression on retrieval from a doc; if the list is
null, the ListProperty returns None.

I argue that there is an important semantic difference between [] and
None in python; one is an empty list, the other is an absence of a
list. In my schema, I have a tags ListProperty. It makes sense for a
newly created record to have no tags ( empty list ) but not for it to
have an absence of a list of tags (None). It also breaks some
assumptions I make elsewhere in couchdb, specifically update handlers,
shows, etc.

I'd like to see this behaviour reverted, i.e. go back to [] being an
acceptable ListProperty value if required=True, and mapping of an
empty list in a stored couch doc via the ListProperty to be an empty
list, not None.

[Benoit Chesneau]

On Jun 20, 6:08 pm, Joan Touzet <jo...@cloudpic.com> wrote:
> Hi there,
>
> Prior to the current code in the couchdbkit git master, if I created a
> schema with a ListProperty(required=True), I could save an empty list
> [] and couchdbkit would pass it. Now, if required=True, this is
> invalid.

Can you give me the version you were you using before using the
master ? Would help to bisect changes.

>
> There is also a regression on retrieval from a doc; if the list is
> null, the ListProperty returns None.
>
> I argue that there is an important semantic difference between [] and
> None in python; one is an empty list, the other is an absence of a
> list. In my schema, I have a tags ListProperty. It makes sense for a
> newly created record to have no tags ( empty list ) but not for it to
> have an absence of a list of tags (None). It also breaks some
> assumptions I make elsewhere in couchdb, specifically update handlers,
> shows, etc.

+1

>
> I'd like to see this behaviour reverted, i.e. go back to [] being an
> acceptable ListProperty value if required=True, and mapping of an
> empty list in a stored couch doc via the ListProperty to be an empty
> list, not None.

Does it make sense for others too? Are some people already based their
code on this change in master ? How do you handle it in this case?

- benoît

[Travis Jensen]

Does it make sense for others too? Are some people already based their 
code on this change in master ? How do you handle it in this case? 

While I haven't gotten the new code yet, I am depending on the same behavior as Joan. My example: I have a user object with a set of roles attached to it. By default, a person has no roles (an empty list), but he must have a list of roles. 

Perhaps it makes sense to have both notions of "there must be a list here" and "there must be a non-empty list here".

tj