Extending resource dicts.

[LarryEitel]

Say I want to extend people schema in settings to lets say users.

So I:

import copy
users = copy.deepcopy(people)
users['schema']['username'] = {
            'type': 'string',
            'minlength': 1,
            'maxlength': 10,
        }

That seems to work OK. However,

Suppose I want to send people and users to the same collection, lets say 'contacts'. Is there a way to designate the name of the collection on a per resource basis? Perhaps:

people['collection'] = 'contacts'
users['collection'] = 'contacts'

After going around several flask/mongodb 'packages', am back again reviewing your project. Your video is great! Thanks to providing a complete functional package along with working examples, it is now possible to expedite building a project on eve.

Thank You :)

[nicolaiarocci]

Thanks for this.

Given the schema-less nature of MongoDB this would make sense. However I wonder how a SQL data layer would handle this feature. I guess that an API maintainer using a SQL backend would just ignore the feature. Also, if there's a SQL backend Eve could ignore/disallow the setting. Thoughts?

PS: currently we don't have a SQL data-layer, but one day I'd love to have one, maybe contributed by someone else. Some basic infrastructure is in place already.

[nicolaiarocci]

Drats. Wrong commit reference ;-)

[LarryEitel]

Here are some things I am doing with 'eve' schemas. This is a work-in-progress. Comments/suggestions are welcome.

[nicolaiarocci]

I have a prototype which is sort of working now. I'd use another keyword, maybe source or even datasource instead of collection, to be more db engine-agnostic. What do you think?

[LarryEitel]

That sounds good. I am trying to cram on a project where I have yet again embarked on a refactoring of code. This time using your library. The biggest challenge I see for me is the ability to extend vs assimilate your project. I appreciate the subtle updates to your cerberus library. I was debating whether I would need to abandon that in favor of schematics. Your latest enhancements enabled me to move forward. I still need to resolve how to decorate endpoints for auth/security. ANY thoughts would be appreciated.

[nicolaiarocci]

Schematics is more feature rich, mature and complex than Cerberus. I know because I contributed to it, even if only a tiny bit. I also contributed to Validiction, another interesting alternative that you might want to check out. After evaluating and contributing to several solutions I decided to write my own, not because the others were missing features (the contrary might be true actually), but because I felt that I wouldn't feel comfortable relying on 3rd party codebases for such a fundamental feature as validation (at that time Schematics was called DictShield. Since then the tool has seen heavy refactoring, and quite the change of focus). Both Cerberus and Eve are so young. I intend to leave Cerberus as light as possible, I don't see it becoming a Schematics competitor (not anytime soon however).

On authorization, frankly I haven't been focusing on it. I know, it sounds crazy, but I first want to add more essential features to the core, and there's so much to do. Surely people will want to implement their own auth, but Eve will support auth natively one day. This being said, I think that decorators are a good way to go (Adam, Eve's closed-source progenitor, implements auth via decorators).

PS: default values for resource items are coming, I think it was you who asked about them on the Cerberus repo? If so, would you please open a ticket here? Closing tickets makes me a happy dev :)

[nicolaiarocci]

b15bbc94fe89aaf0196766236b9d650256b21227