Should EmbeddedDocument child of abstract EmbeddedDocument have a cls field? about umongo

[touilleMan]

Don't worry for the mess ;-)

I think the difference between embedded document and document is due to the fact a document is linked with a collection:

• Abstract document ==> no collection, cannot be instantiated
• Regular document ==> collection
• Regular Child document ==> same collection than it parent, get a cls field as discriminent

On the other hand, and embedded document has nothing to do with collections. However given it implementation comes from the document's one (doctstring of EmbeddedDocumentOpts.abstract shows this for example ^^), it get the abstract system.

I tried to fix what you described (see f834177):

• Abstract embedded document and it direct children don't provide cls field
• Abstract embedded document cannot be used in EmbeddedField

However I'm not sure this is the right way to do: is abstract really meaningful for embedded document ?
Without abstract, you would just define regular class (not EmbeddedDocument) to make my abstract inheritances, then use multiple inheritance to create concrete class.

This is typically what I would do to solve your current usecase btw:

 class TimedEmbeddedDocumentMixin:
    created_at = DateTimeField()
    updated_at = DateTimeField()

class MyEmbeddedDoc(TimedEmbeddedDocumentMixin, EmbeddedDocument):
    foo = IntField()

So maybe we could just put a word about this pattern in the EmbeddedDocument documentation and drop the abstract stuff from it.

What do you think ? Do you see a special usecase that would require abstract for the embedded document ?

[lafrech]

An approach to adding common methods to EmbeddedDocument could be to add a BASE_EMBEDDEDDOCUMENT_CLS to BaseBuilder with EmbeddedDocumentImplementation as default and overload PyMongoBuilder to provide our superclass. This could be an interesting feature request.

Our use case is a bit wider than this, though. We can have for instance:

        class TimedEmbeddedDocument(EmbeddedDocument):
            created_at = DateTimeField()
            updated_at = DateTimeField()

Some EmbeddedDocuments would inherit from EmbeddedDocument, others from TimedEmbeddedDocument, or some other EmbeddedDocument subclass.

As opposed to Vehicle, there is no semantical link between TimedEmbeddedDocument and Car or Truck. I don't see a point for

    field = EmbeddedField(TimedEmbeddedDocument)

Maybe we're trying to factorize too much.

Anyway, the more I think of it, the more I think current behaviour is correct.

We just need to find a reasonable way to remove those cls from the serialization.

I definitely need to think this through. I'll get back to you when my mind is clearer about it all.

Sorry about this mess...

[lafrech]

Hi. Sorry for not answering any sooner.

I'm not used to mixins, and I don't know the pitfalls, but I blurrily remember there are pitfalls and I should have a clearer understanding of the MRO before using them, so I generally stick to "classical/linear" inheritance and scarcely use mixins. Therefore I can't provide educated feedback about this.

I like the abstract EmbededDocument idea. But I could probably live (just a guess, I didn't test) with the mixin approach if you prefer to follow that path.

[lafrech]

Mixins don't work (#188).

[lafrech]

I think both approaches (Mixin and base class) have their use case.

Typically, I'd use a Mixin to provide additional fields on some documents:

 class TimedEmbeddedDocumentMixin:
    created_at = DateTimeField()
    updated_at = DateTimeField()

class MyEmbeddedDoc(TimedEmbeddedDocumentMixin, EmbeddedDocument):
    foo = IntField()

and I use a base class to provide additional methods to my base document, like wrappers to base methods, etc.

I pushed a PR fixing the Mixin issue (#267).

And I rebased @touilleMan's work on this in #269.

[lafrech]

Regarding the removal of cls field when dumping mentioned in OP, it is more or less unrelated.

I use a custom schema for this right now.

class ExtraSchema(SchemaFromUmongo):
    """Custom Marshmallow Schema for our Schemas"""

    # XXX: This kinda sucks. Deal with it in umongo?
    def _init_fields(self):
        super()._init_fields()
        self.fields.pop('cls', None)
        self.load_fields.pop('cls', None)
        self.dump_fields.pop('cls', None)

This might be worth a umongo feature...