simultaneous multiple requests to very simple database
Eric S. Johansson
esj at harvee.org
Tue Jan 18 23:33:26 CET 2005
Thomas Bartkus wrote:
> "Eric S. Johansson" <esj at harvee.org> wrote in message
> news:mailman.859.1106065617.22381.python-list at python.org...
>>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. ;-)
> 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