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
