On 11/13/2009 10:42 AM, Adam GROSZER wrote:
> 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 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:
ZODB-Dev mailing list - ZODB-Dev@zope.org