On Sun, May 24, 2009 at 7:40 AM, lasizoillo <[email protected]> wrote: > > 2009/5/24 Jorge Vargas <[email protected]>: > You can test also Durus[2]. Durus have a storage backend over > BerkeleyDB[3] (performed by the core bsddb maintainer). You can extend > it to provide replication, distributed transaction, ... and a lot of > stuff provided by berkeley db without change the durus frontend. > > Durus is very pythonic, is documented in pylons and you can prove > diferents backends easily because Durus is simple. You can write a > pythonic trie structure for fulltexsearch index and save it to durus > easily. Berkeley DB have a lot of tools to recover a database, > performs hot-backups, and a lot of stuff [4].
Durus is great, but it does have issues in multithreaded/multiprocess programs. If the database is read-only, you can open the file in each process/thread, and the only overhead will be duplicating the memory cache among the processes. (Durus likes to keep retrieved records in memory, at least in my experience.) If the database is read/write, you'll have to use the server daemon. I haven't used it so I don't know if it would also lead to a duplicate memory cache in the server. ZODB has a thread synchronization layer, so it should work out of the box in a multithreaded program. -- Mike Orr <[email protected]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en -~----------~----~----~----~------~----~------~--~---
