On 11/13/2009 10:42 AM, Adam GROSZER wrote: > Hello, > > I think we can look at this at 2 levels. > > 1.: As your app uses ZODB. Then this is your app's > problem/reponsibility. You use a nosql contender directly from > your app and it's your responsibility to deal with it. > > 2.: On the ZODB Storage level. So far I can see that level needs > consistency, transactions and locking support. Those are usually > missing from nosql implementations (unless I miss some). > OTOH a key-value store would fit the ZODB storage. > If someone finds/writes a key-value storage that has the above > properties we could give it a try.
Looking at the article referenced by Shane I understand that we'd have to drop consistency for being able to use such a store -- I feel that's not a good idea in the face of ZODB. The applications we write are intended to run consistently without having application-level (or even user-based) reconciliation work to do if a transaction came through. Apart from the stores being hip ... what problems are you trying to solve? Christian -- Christian Theune · c...@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development _______________________________________________ For more information about ZODB, see the ZODB Wiki: http://www.zope.org/Wikis/ZODB/ ZODB-Dev mailing list - ZODB-Dev@zope.org https://mail.zope.org/mailman/listinfo/zodb-dev
