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 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

Reply via email to