No License

[kidrecursive]

Hi, thanks for your work on this project.

There is no license attached to the project, do which license do you intend to release this code under?

Thanks.

[kidrecursive]

Well, I just noticed this:

setuptools.setup(
    name="Mongothon",
    version="0.3.0",
    author="Tom Leach",
    author_email="tom@leach.it",
    description="A MongoDB object-document mapping layer for Python",
    license="BSD",
    keywords="mongo mongodb database pymongo odm validation",
    url="http://github.com/tleach/mongothon",
    packages=["mongothon"],
    long_description="Mongothon is a MongoDB object-document mapping " +
                     "API for Python, loosely based on the awesome " +
                     "mongoose.js library.",
    install_requires=['pymongo'],
    tests_require=['mock', 'nose']
    )

So BSD it is, sorry for the bother.

[tleach]

Yeah it's BSD.

If you have any other questions / requests etc let me know. This library is definitely in alpha right now but the plan is to use and build on Mongothon at my company in the coming few months so watch this space.

[kidrecursive]

Sure, I've been working on a fork of it the last few days to add some specific features that I need, we can discuss more in depth offline if you feel like you would like to take the lib in that direction. Basically my changes have been to:

1. Make Model declaration/usage more OO
2. Allow schemas to be inherited from parent models
3. Use drivers so that the schema/validation layer is separate from the persistence layer (for example, MongoModel inherits from Model and implements the pymongo interface for MongoDB interaction). I needed to support polyglot persistance but wanted to keep schema and model API consistent across datasources, so that's why this is there.

Those are the major structural changes and represent a change in philosophy of the lib, so I understand if you don't feel like they need to be merged in.

[tleach]

Interesting stuff.

1. This is just a style preference thing in my mind.
2. This is interesting. Generally I tend to prefer composition to inheritance for this sort of thing. I have vague plans to introduce the concept of reusable "traits" which can be mixed in to schemas. But it's not a priority right now.
3. Definitely agree that schema/validation should be separate from persistence. I had intended to ultimately support multiple stores which is why the the schema/model decoupling exists in the first place. However this is not the most important thing for me right now. If I was to do it, again I think I'd steer away from an inheritance-based approach and use a composition approach to allow a driver to be provided to create_model when generating a dynamic model class... probably. :-)

In any case, I will of course backport some of your fixes (I'm relatively new to Python and never realized callable() was a thing). More than happy to discuss debate this stuff some more :-).

[kidrecursive]

I use composition a lot for schema's in Mongoose. In Python you get some goodies that allow you to do things in a more OO fashion so that's the reason I made that change, it's a style preference as you say.

One thing I started to work on is extensible types for schemas, so you could have 'type':Reference, or create whatever you like. This is similar to mongoengine's field system which works really well. For instance you could have a list type and apply validators/defaults to it as opposed to just being able to set a base type or have an embedded document.

[tleach]

I like the extensible types idea, though bear in mind you can already do embedded lists/collections by using the [child_schema] notation allowing each list item to validated using a child schema. Or are you saying you want to validate the length of the list?

[kidrecursive]

Yep, something like that, or only allow certain strings etc inside of a list.