Comments on: ZODB vs. pysqlite with SQLObject

By: Blue Sky On Mars » MichiPUG this week: ZODB

Blue Sky On Mars » MichiPUG this week: ZODB — Mon, 30 Jun 2008 11:58:07 +0000

[...] meeting, where I led us in a random experiment with Google App Engine, I actually have some experience with the [...]

By: Sridhar Ratna

Sridhar Ratna — Fri, 07 Oct 2005 20:05:25 +0000

Atop is dead. Long live Axiom - http://www.divmod.org/projects/axiom

By: Marco

Marco — Fri, 05 Aug 2005 16:39:37 +0000

probably you should also have a look at Atop

“”"
ATOP, the Atomic Transactional Object Persistor, is a Python object database implemented atop the Berkeley DB and bsddb python module, with functional similarities to other python packages such as ZODB and COG.
“”"
from the Atop project site - http://www.divmod.org/projects/atop

By: David Binger

David Binger — Wed, 06 Jul 2005 14:43:27 +0000

Re: ComputedAttributes and _v_ attributes.
Unlinke _v_ attributes in ZODB, ComputedAttributes provide a mechanism
for invalidating data in other connections to the database. This makes it
possible to maintain consistency of information derived from other persistent
instances.

The ComputedAttribute class in Durus is simple and doesn’t rely on any feature of Durus that is not also present in ZODB. You could do the same thing in a ZODB application

By: tazzzzz

tazzzzz — Sun, 03 Jul 2005 19:17:56 +0000

Probably the only reason to choose Gadfly over sqlite is if you want to distribute one set of .py files, instead of having platform-specific binaries.

While working with the ZODB, I did take a look at AdvancedQuery. Nice stuff, and you’re probably right that it would work outside of Zope with a little work. I didn’t mention it in the main article, because ZCatalog is enough to get you querying…

By: azazel

azazel — Sun, 03 Jul 2005 14:38:10 +0000

another useful tool to do advanced querying on catalogs is Dieter Maurer’s AdvancedQuery, http://www.dieter.handshake.de/pyprojects/zope/AdvancedQuery.html

Probably it can adapted to run without zope with a minor effort

By: Enrique

Enrique — Sat, 02 Jul 2005 15:22:59 +0000

Anyone read about Gadfly?. A simple, in memory SQL python database. Not really a “proffesional” database, but good enough for “light-weight” desktop projects (much better than using access for example), and have not problems to store small images or files through Python pickle. I have used it in tens of projects with zero problems to recover from power failures up to date.

By: Mario Ruggier

Mario Ruggier — Fri, 01 Jul 2005 07:09:21 +0000

Given that Durus has already been mentioned above, i’d like to further add a few comments regarding (a) Durus itself, (b) one of the things you said in the article concerning sqlite: “The downside is that you’re still doing mapping so you can’t completely forget about the fact that there’s a relational database back there.”, and (c) regarding the lack, on the other hand, of out of the box “querying ability” of ZODB).

To facilitate using Durus, I have made a small light layer, moellus, that adds precisely some very useful “relational-like” characteristics to the database’s organization… this way, I can help benefit from these (having, for example, some querying abilities out of the box), but still have a perfectly fine object graph with all of my objects. The Durus feature mentioned above, ComputedAttribute, is also used heavily to automate things such as the inverse of a many-to-one relationship, that can therefore be available simply by declaration.

However, there is object-relational mapper in sight, as there is none! A pure object graph, with some model and organizational impositions…

I have actually released a first version recently, that can be found at:
http://scoopics.com/software/moellus/

And, there is now also a presentation, just hot off the europython2005 press:
http://www.python-in-business.org/ep2005/talk.chtml?talk=2092&track=692

By: tazzzzz

tazzzzz — Fri, 01 Jul 2005 01:09:01 +0000

That is true, and a good point. But, you do have to carefully consider how you do things. Here’s the sqlite page about locking:

http://www.sqlite.org/lockingv3.html

Section 7 (all the way at the end) tells the most relevant part of the locking story.

pysqlite2’s handling of transactions is done well, because it doesn’t start a transaction until you run a statement that does some kind of database modification. That avoids getting a SHARED lock too early.

Thanks for bringing up the point of exactly how sqlite handles locks. It is very relevant for anyone considering it.

By: Piet Delport

Piet Delport — Thu, 30 Jun 2005 21:50:58 +0000

Note that since version 3, SQLite no longer needs an exclusive lock for the entire duration of a write operation (instead, it’s only needed briefly, during the final stage of the commit). In other words, you *can* still read from the database without blocking, while a lengthy write operation is going in the background.