Usage problem: can't delay configuration until after model class declaration.

[Olivier Ozoux]

I'm having a problem figuring out where/when to call minimongo.configure() in my Pyramid app, to make sure that my minimongo class actually have a valid connection to the database.

The whole metaclass thing is causing the connection to be created when the module is imported and the class declaration is parsed, which is way before I've had a chance to read my setting files and get valid values for host and database.

It seems that I can't write an example like this in a single file:

import minimongo


class MyModel( minimongo.Model ):
    """Base MiniMongo model. all models should inherit from this one"""
    class Meta:
        """Collection definition should go here."""
        colection = "test"


def main():
    minimongo.configure(
        host = "mongo.ozoux.com",
        database = "test"
    )
    a = MyModel()
    a.name = "foo"
    a.save()


if __name__ == '__main__':
    main()

I get the following error:

 File "test_minimongo.py", line 21, in <module> 
 class MyModel( minimongo.Model ):
 File "minimongo/minimongo/model.py", line 49, in __new__ 
 (name, options.host, options.port, options.database)
 Exception: Model 'MyModel' improperly configured: localhost 27017 None

How exactly can I use minimongo with a deferred configuration call? I'd like to be able to define my models wherever I want, and as long as the call to configure happens before the class is instanciated, everything should be fine, no?

[Steve Lacy]

Hi, sorry for the delay, was quite busy with my other project.

In development, I'm calling configure() in my init.py that runs the paster script. In production, I actually bubble it way up into the WSGI script that I use for deployment.

[Olivier Ozoux]

Ok that's what I figured.

However, as I was working to replace some of the stuff I already had in place, and start integrating minimongo, I realized that my requirements were already taking me down a path that was somewhat parallel but different enough that I needed to create my own abstraction layer instead.

It's unfortunately far enough as to no longer really be a fork any more.

1. Collections are first class citizens. (matches my Pyramid resource structure, /collection/document )
   also allows me to create filtered collections which supports the following pattern
   /collectionA/documentB/collectionB_related_to_documentA/document B .
2. Delayed initialization. Not only can't I guarantee that I'll know what the default hostname/database will be before loading the module (and therefore using the metaclass transformation trick) I often need to create instances of my Collection objects in advance as well.
3. Lastly I need to make sure that all of the Collection objects that share the same database, actually use the same pymongo database object, so that any SONManipulator that are added to it are valid for all.
4. although I appreciate the convenience of typing foo._id over foo['_id'] I usually find that by the time you overlay other functionality on the object and need to create custom properties and methods, the chances that your properties are going to mask one of the keys of a document become really high. I'd rather not have to worry why sometimes foo.name == foo["name"] and sometimes not.

[Mark Grey]

Didn't actually realize one could delay configuration like that. This would be handy for swapping collections/dbs for unit testing purposes.

Should I omit the hosts from my Model declarations and rely on a later call to configure to hook it up?