semantics/meanings of wrapper/schema/classes for db.get vs db.view vs Document.view as well as _allow_dynamic_properties

[Ronny Pfannschmidt]

hi,

to finish the work on the ViewResult refactoring i did, various semantics need to be clarified

1. the meaning of wrapper/schema/classes in various places, and how to unify
2. the intents on Document vs StaticDocument wrt _allow_dnamic_properties for ViewResults/ Document.get_or_create

----------------------------------------

current state on wrapper/schema/classes + _allow_dnamic_properties

Database.get
   wrapper -> single doc wrap
   schema -> single class
Database.view
  wrapper -> row wrapper (not document)
  schema -> class or list of classes, messes around with _allow_dynamic_properties
Document.view
  * messes around with _allow_dynamic_properties
  classes -> list of classes that will replace the own Document class if given
  wrapper -> row wrapper
Document.get_or_create
  * messes around with _allow_dynamic_properties
  * takes params instead of ctor args


in my branch ( https://github.com/benoitc/couchdbkit/pull/128 ) _allow_dynamic_properties is no longer touched by views by default, the rest is still the same

my desired state would be

SchemaMapper: object that maps json data to Document instances,
                         * should be constructable from class, list of classes or a SchemaMapper
                         * should not touch _allow_dynamic_properties (but currently does),
                           instead it should use something like type(cls.__name__, (cls,), {'_allow_dynamic_properties':dynamic_properties}) if it differs

*note* i just realized that SchemaMapper is mostly a conceptual thing for constructing a proper wrap function + its mapping

Database.get
   wrapper -> single doc wrap
   schema -> SchemaMapper
Database.view
  wrapper -> row wrapper (not document)
  schema -> SchemaMapper
Document.view
  classes -> SchemaMapper
  wrapper -> row wrapper
Document.get_or_create
  * should not touch _allow_dynamic_properties
  * kwargs are ctor args

[Benoit Chesneau]

On Apr 23, 2012, at 4:05 PM, Ronny Pfannschmidt wrote:

> hi,
>
> to finish the work on the ViewResult refactoring i did, various semantics need to be clarified
>
> 1. the meaning of wrapper/schema/classes in various places, and how to unify
> 2. the intents on Document vs StaticDocument wrt _allow_dnamic_properties for ViewResults/ Document.get_or_create
>
> ----------------------------------------
>
> current state on wrapper/schema/classes + _allow_dnamic_properties
>
> Database.get
> wrapper -> single doc wrap
> schema -> single class
> Database.view
> wrapper -> row wrapper (not document)
> schema -> class or list of classes, messes around with _allow_dynamic_properties

> Document.view
> * messes around with _allow_dynamic_properties
> classes -> list of classes that will replace the own Document class if given
> wrapper -> row wrapper
> Document.get_or_create
> * messes around with _allow_dynamic_properties
> * takes params instead of ctor args
>

We should remove all these Document db methods. Everything should be handled with the db object . Document would be then only be a mapping with validation. The django case need to be investigated but I think it's easier in this case since db are registered during djago initialization. We should make sure anyway to pass the db instance only to Document instance

>
> in my branch ( https://github.com/benoitc/couchdbkit/pull/128 ) _allow_dynamic_properties is no longer touched by views by default, the rest is still the same
>
> my desired state would be
>
> SchemaMapper: object that maps json data to Document instances,
> * should be constructable from class, list of classes or a SchemaMapper
> * should not touch _allow_dynamic_properties (but currently does),
> instead it should use something like type(cls.__name__, (cls,), {'_allow_dynamic_properties':dynamic_properties}) if it differs
>
> *note* i just realized that SchemaMapper is mostly a conceptual thing for constructing a proper wrap function + its mapping
>
> Database.get
> wrapper -> single doc wrap
> schema -> SchemaMapper
> Database.view
> wrapper -> row wrapper (not document)
> schema -> SchemaMapper
> Document.view
> classes -> SchemaMapper
> wrapper -> row wrapper
> Document.get_or_create
> * should not touch _allow_dynamic_properties
> * kwargs are ctor args
>
>

I think a view or a Document object should be able to raise an error or ignore (bosth should be an option) unknown properties, ie though not present in the Schema. For that I propose to have :

db.view(***, ignore_unknown_properties=False, raise_on_unknown_properties=False)

(options names need to be shorted imo).

And a StaticSchema which would inherit from Schema but where __setitem__ and __setattr__ would raise or ignore any unknown properties..


I think we should follow that way. About the wrapper and co, mayb ewe could imagine a generic way to create it?

- benoît

[Ronny Pfannschmidt]

Hi,

i suppose Database would need a get_or_create method as well (taking a schema)
as for dealing with dynamic properties, we might want to employ policies for that (so it can be add, raise or ignore, where add will just imply raise for Static

wrt the generic wrappers, the latest version of my branch has something in couchdbkit.schema.utils thats better
but we need some more thought wrt row wrapping vs document wrapping