-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Very cool and excellent work.
Andreas Stephan Richter wrote: > Hi everyone, > > as you might have seen from my checkins on Friday, I released > mongopersist. In short, it implements a persistence backend in > MongoDB (that, with a little bit of effort, could be used as a ZODB > replacement in Zope): > > http://pypi.python.org/pypi/mongopersist > > Some background and motivation: > > Many years ago, Jim told me that the persistence code could be used > to implement any storage backend. But until now I never had the need > to confirm that statement. The ZODB and its various storages served > me just fine. But then I decided to use MongoDB as storage for my > latest project. (I just recently used storm with PostGreSQL for a > project and was once again annoyed about the impedance mismatch > between the stiff relational and flexible object worlds.) > > It was out of question that I just wanted to use pymongo straight up, > since it makes admin interfaces just very painful to write. I first > tried p01.mongo, but unfortunately it tries to re-implement > persistence with some of the most annoying ORM-style features (such > as explicit attribute declarations). > > So, I came to the conclusion I wanted to build an abstraction layer > myself and see how well it would work. An ORM-style solution was out > of question. I consider attribute-type declarations ORM-style, since > it prohibits me to extend objects in arbitrary ways (think > annotations, sub-classing, etc). I then looked into implementing a > ZODB storage. Unfortunately, the ZODB really wants to deal with > pickles and I wanted to store objects in a way that the data could be > used without Python. > > Thus, implementing a storage mechanism on top persistence seemed like > the best choice. It was not too hard, since ZODB's storage > implementations provided good examples. Here are some of the main > features: > > * Full persistent data manager implementation making storing objects > seamless. > > * Data manager can be used to load and dump objects directly. > > * Automatic and explicit specification of the mongo collection to > use. > > * Store multiple object types in the same collection. This is > particularly useful, if you have sub-classes of an object type. > > * Storage of non-persistent objects. Pretty much everything that can > be pickled can be stored. There is some work left to do to support > all pickle hooks and object constructors. > > * Plugins to provide custom serializers and de-serializers for > objects. This is useful for objects whose reduced state is not > suitable for Mongo storage, such as datetime.date. > > * Control over document granularity. In the ZODB, any persistent > object causes a separate pickle/document. In mongopersist you can > choose whether a persistent object is stored as part of its parent > object or not. (The Mongo guys make a big deal about choosing > document granularity.) > > * Cross database support, i.e. full DBRef object references are used > everywhere. > > * Optional write-conflict detection. > > * Simple Mapping implementation that represents a collection. > > * Optional Zope Support: Multiple container implementations for > various use cases. The main container supports one collection for > multiple instances by keeping a parent reference. The container > itself can be connected to a ZODB or mongopersist. The container also > provides full access to the MongoDB query API, filtering by parent > automatically and supporting raw or object results. > > Before you jump on this right away, here are some features that are > missing: > > * BTreeContainer instances will probably store, but they would not > provide sensible output in Mongo. Custom hooks need to be written to > handle BTreeContainers sensibly. > > * Since the pickle module does not cleanly separate reducing an > object and creating a pickle string, mongopersist must effectively > re-implement the pickle API. I have implemented the most common use > cases, but some pickle hooks and handling of classes with __new__ > constructors are still missing. > > * Cyclic references of non-persistent objects is not supported. > > That said, we are about to head into production with mongopersist. If > you need any help or want those above two problems addressed, feel > free to contact me. > > So was Jim right? Absolutely! > > Regards, Stephan - -- ZOPYX Limited | zopyx group Charlottenstr. 37/1 | The full-service network for Zope & Plone D-72070 Tübingen | Produce & Publish www.zopyx.com | www.produce-and-publish.com - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQGUBAEBAgAGBQJOuUnuAAoJEADcfz7u4AZj7Z4LwKPmjsATpiOvlf1s/KsH49l3 x0ky1sLmeCeyQkcafTdo+jxXvPrmDvy1N8bVFBoL2ciXgEatC4VWAo6qJfJ7ozHq CPsdNhEqACEcvZhTkACqsKKaY/tsPerKafW1eafFfnZEISWJLgOUCR4WPGY+HAdf OMSe6DZqwzI2/w52b8IGWlmeAw/xIjzvRHui1h/0hb/cxaiGoet7AVAUqNbeQ4Mf e+jqN/u1pVRbebJ3MWhYkexmKAm4tFQOptesSgS4KmTEFadvT5ngOn1X63PZtibx cJcRO4wK/+5d4hlyAOlQl05bqRndla3c+Bqe8Bs03FajMMGX/95WqwmavSXUsmTf tKODvflQ+jlL3chzXNUdJHflkKgzgxshwpZEAZuSrx8Tjlzwb8Ab30LAx6XtqADM +ftiDRNt60N36L+cI7cBt+VK9arOihHiuV2zBpk8GQK4rZS1jGfN2nQKsX6DDT+I MDDvLuuHODaBIp0I2BYRqZzzEDmw1t4= =JsOP -----END PGP SIGNATURE-----
<<attachment: lists.vcf>>
_______________________________________________ For more information about ZODB, see http://zodb.org/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
