simultaneous multiple requests to very simple database

Eric S. Johansson esj at
Tue Jan 18 23:33:26 CET 2005

Thomas Bartkus wrote:
> "Eric S. Johansson" <esj at> wrote in message
> news:mailman.859.1106065617.22381.python-list at
> <snip>
>>at this point, I know they will be some kind souls suggesting various
>>SQL solutions.  While I appreciate the idea, unfortunately I do not have
>>time to puzzle out yet another component.  Someday I will figure it out
>>because I really liked what I see with SQL lite but unfortunately, today
>>is not that day (unless they will give me their work, home and cell
>>phone numbers so I can call when I am stuck. ;-)
> <snip>
> Forgive me if this reply sounds a bit glib. But I do mean it without malice.

understood and taken in that spirit.

> Do you seriously expect to write your own (database) solution and that this
> will save you time and effort over learning an existing (SQL) solution?
> Because -
> If you are seeking to "save time" on "puzzles", you are certainly going
> about it the wrong way.

one thing I learned a long time ago was to respect the nagging voice in 
the back of my head that says "there is something wrong".  Right now 
with databases, that voice is not nagging but screaming.  So I made my 
query to try and prove that intuition wrong.  So far, that has not happened.

When I look at databases, I see a bunch of very good solutions that are 
either overly complex or heavyweight on one hand and very nice and 
simple but unable to deal with concurrency on the other.  two sets of 
point solutions that try to stretch themselves and the developers to fit 
other application contexts.

99.9 percent of what I do (and I suspect this could be true for others) 
could be satisfied by a slightly enhanced super dictionary with a record 
level locking.  but, the database world does not fit this model.  It has 
a great deal more complication then what is frequently necessary.

If I ever find the time, I will try to build such a beast probably 
around Metakit.  The only reason for reluctance is that I have spent too 
many hours tracking down concurrency problems at the OS level way to 
many years ago and so I do not create multithreaded applications lightly.

so in conclusion, my only reason for querying was to see if I was 
missing a solution.  So far, I have not found any work using because 
they add orders of magnitude more complexity than simple dbm with file 
locking.  Obviously, the simple solution has horrible performance right 
now I need simplicity implementation.

thanks for your commentary.


More information about the Python-list mailing list