pure Python DB

P

Patrick Useldinger

Hello,
for a cross-platform project, I am looking for a Python DB. It should be
lightweight, but provide transactions an of course reliable.
Is there such a thing out there?
I have read about Gadfly, is this still maintained?
Thanks,
-Patrick
 
A

Andy Todd

Patrick said:
Hello,
for a cross-platform project, I am looking for a Python DB. It should be
lightweight, but provide transactions an of course reliable.
Is there such a thing out there?
I have read about Gadfly, is this still maintained?
Thanks,
-Patrick

Gadfly is lightweight but doesn't support transactions. It is in low
maintenance mode, development is currently not active but the project is
hosted at SourceForge (http://sourceforge.net/projects/gadfly) and any
bug reports and (especially) patches would be more than welcome.

Regards,
Andy
 
P

Paul D. Fernhout

Patrick-

You might try out the Pointrel Data Repository System I wrote -- it's
all in Python.
http://sourceforge.net/projects/pointrel/

You need to learn to frame the data storage problem in its terms (triads
or somewhat Entity-Relation-al, similar in some ways to RDF). It does
provide single-user transactions using a lock file, but this lock file
approach has not been tested on lots of platforms. Compared to other
systems, you might find it less efficient in disk use (it now supports
64 bit offsets) and more difficult to delete thigns (the short answer
is, you can't delete anything -- without writing application level
support on top of it). On the plus side, you only need to add one
Python file to your project.

However, it does not yet have the level of testing yet one might want
for something mission critical. Naturally, how well suported it is is a
matter of chicken and egg -- if it is not well supported people won't
try it or improve it (until it magically makes it over some level of
general interest). For an example of its current bleeding edge state, I
just discovered what I think may be a potential bug where abandoned
transactions could create problems if you are using caching (the cache
could hold onto no longer valid handles for added new strings) -- I've
patched that for the next release (and you can always just turn off
caching), but that's the sort of bleeding edge thing you might encounter
if you try it. You can see the recent announcement of the latest version
in comp.lang.python.announce.
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&th=6de75a999a0ca969&rnum=3
Or this recent post:
http://groups.google.com/groups?hl=...-8&[email protected]&rnum=5

I can say that I'd be interested in making the Pointrel Data Repository
a stable and well supported popular platform, although I won't commit to
any specific time frame or level of effort for it. I think it would be
more ready to go when or if I make the transition to using it to store
all my email (gulp -- that's commitment! :) But that hasn't happened
yet. I'm thinking of using it in a web proxy first as that's a little
more forgiving application area for me (but the issues of making a good
proxy are stalling that some).

A year or two or so back I looked at the Gadfly source with a notion of
using some of it to put a SQL front end onto Pointrel. Maybe that would
make it more apalatable for general use? But I'm not generally
interested in using SQL, so I'm not sure how far down that road I want
to go.

In any case, all the best. And the databases written in C might be worth
your exploration -- some of the appear to be quite good and fairly cross
platform in their own terms.

--Paul Fernhout
 
A

Aaron Watters

Andy Todd said:
Patrick Useldinger wrote:>
Gadfly is lightweight but doesn't support transactions. It is in low
maintenance mode, development is currently not active but the project is
hosted at SourceForge (http://sourceforge.net/projects/gadfly) and any
bug reports and (especially) patches would be more than welcome.

Um.. doesn't support transactions? It depends what you mean,
I guess. It supports transaction commit and rollback and recovery
but not transaction concurrency... (yet)

-- Aaron Watters

===
She's wondering what he'll make for breakfast...
He's wondering how long he has to cuddle before he can go home...
 
?

=?ISO-8859-1?Q?Gerhard_H=E4ring?=

Aaron said:
Um.. doesn't support transactions? It depends what you mean,
I guess. It supports transaction commit and rollback and recovery
but not transaction concurrency... (yet)

Neither does SQLite. Only one transaction can be active at any time.
Another transaction will block at BEGIN.

If you need that I'd suggest you switch to a client-server database like
PostgreSQL.

-- Gerhard
 
D

David Rushby

Gerhard Häring said:
Neither does SQLite. Only one transaction can be active at any time.
Another transaction will block at BEGIN.

If you need that I'd suggest you switch to a client-server database like
PostgreSQL.

No need to go client/server. Embedded Firebird supports concurrent
transactions with configurable isolation levels, foreign keys, views,
stored procedures, and other features one would expect from a
full-fledged RDBMS. Plus it's fast--kinterbasdb with embedded
Firebird 1.5-rc4 is about twice as fast as pysqlite 0.4.3 in various
trivial speed tests I've tried.

Embedded Firebird is not the primary focus of the Firebird core
developers, though, so releases aren't always up to date, and so far,
binaries have only been released for Windows. Here's the most recent:
http://prdownloads.sourceforge.net/firebird/Firebird-1.5.0.3744_RC4_embed_win32.zip?download

To use it from Python, see:
http://cvs.sourceforge.net/cgi-bin/...0/docs/usage.html#faq_fep_embedded_using_with

I'm not aware of any reason why embedded Firebird couldn't run on *nix
(the server variant does), but AFAIK no one has done so. Also, I
haven't used the embedded variant for anything non-trivial, so I can't
comment on its stability.
 
?

=?ISO-8859-1?Q?Gerhard_H=E4ring?=

David said:
Gerhard said:
If you need [concurrent transactions] I'd suggest you switch to a
client-server database like PostgreSQL.

No need to go client/server. Embedded Firebird supports concurrent
transactions with configurable isolation levels, foreign keys, views,
stored procedures, and other features one would expect from a
full-fledged RDBMS. [...]

The included README says:

"""
But you should be aware that you cannot access single
database from a number of the embedded servers
simultaneously, because they have SuperServer architecture
and hence exclusively lock attached databases.
"""

So it doesn't help in a multi-process environment, either (like in CGI
scripts). But then again, CGI sucks :p

Embedded Firebird sounds like a good solution for small *multithreaded*
application servers, though.
Plus it's fast--kinterbasdb with embedded Firebird 1.5-rc4 is about
twice as fast as pysqlite 0.4.3 in various trivial speed tests I've
tried.

That's interesting. I wonder how much of that is because of the
relatively inefficient Python wrapper over SQLite. Time to go on with my
prototype for PySQLite 0.5 :)

-- Gerhard
 
P

Patrick Useldinger

In my case, only one process is supposed to acces the DB, but I need to be
able to rollback in case it goes wrong, or to commit only all went right.
 
M

Mark Roach

]
No need to go client/server. Embedded Firebird supports concurrent
transactions with configurable isolation levels, foreign keys, views,
stored procedures, and other features one would expect from a
full-fledged RDBMS. Plus it's fast--kinterbasdb with embedded
Firebird 1.5-rc4 is about twice as fast as pysqlite 0.4.3 in various
trivial speed tests I've tried.

I thought Firebird was a web browser?!


couldn't help myself :)

-Mark
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
474,099
Messages
2,570,626
Members
47,237
Latest member
David123

Latest Threads

Top