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. Thursday, November 12, 2009, 8:24:43 PM, you wrote: SH> Encolpe Degoute wrote: >> Is there someone in the ZODB development team following this: >> http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/ SH> It is possible that ZODB unfortunately occupies the same space as SQL in SH> the CAP triangle: SH> http://camelcase.blogspot.com/2007/08/cap-theorem.html SH> That is to say, ZODB applications require consistency and availability, SH> so if the CAP theorem is true, then ZODB applications can not be very SH> partition-tolerant. SH> The NoSQL databases provide availability and partition tolerance while SH> foregoing absolute consistency. SH> Shane SH> _______________________________________________ SH> For more information about ZODB, see the ZODB Wiki: SH> http://www.zope.org/Wikis/ZODB/ SH> ZODB-Dev mailing list - ZODB-Dev@zope.org SH> https://mail.zope.org/mailman/listinfo/zodb-dev -- Best regards, Adam GROSZER mailto:agros...@gmail.com -- Quote of the day: For a good time, call 836-3100. _______________________________________________ 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