>-----Original Message----- >From: b.bum [mailto:[EMAIL PROTECTED] >Sent: Friday, September 24, 2004 1:34 PM >To: [EMAIL PROTECTED] >Subject: Re: [sqlite] Lock files.... > > >On Sep 24, 2004, at 11:16 AM, Fred Williams wrote: >> I picked SQLite for its minuscule (by today's standards) footprint, >> simplicity, and ease of deployment. >> >> Why do I get the feeling I've bought into a product like any model in >> the >> American car market. With each passing interation the vehicle gets >> bigger, >> fatter, and less efficient. This continues until the model bears >> absolutely >> no resemblance to the original. But, it does have electric fold down >> rear >> seats to the advantage of the totally clueless. >> >> If all these MySQL and PostgreSQL imitator "features" could be >> developed as >> "plug in" modules that leaves SQLite as it was for those who liked it >> the >> way it was when they picked the product, I would not really care who >> did >> what about complex locking situations. >> >> Guess I need to start "shopping" again :-( > >I'm not at all sure why you would draw such a conclusion. > >SQLite3 produces smaller data files and is faster, in general, than did >SQLite2. It also uses its internal data structures more efficiently. > >The ongoing multiple-processes-accessing-the-same-database discussion >is specifically focused on not adding client/server, not adding a >daemon, and on leveraging filesystem based locking to ensure multiple >processes can successfully read/write to a single database file in the >most simplistic fashion possible. > >The request to have an abuse test was not a request to add some complex >locking functionality to SQLite. It was specifically a request to >have a test that ensures that the *** already existing locking features >*** work correctly when multiple processes are beating upon the >database. That is, to test code paths that already exist for which -- >at least as far as I can tell -- there is little testing coverage. > >How is that bloating SQLite? > >b.bum >
Sorry I picked your message to tag on to in the "Locking" thread. I'm just generally saying that with all this effort being applied to things other than those you have highlighted above, makes me nervous. I would like to see SQLite evolve to kick Oracle's b___ just for the fun of it. But, I think making as much functionality possible as configurable options would preserve the original product pretty much as designed therefore retaining the reason most of us picked SQLite in the first place. My applications are all single user, or if multi-user, designed to easily implement either SQLite or a full client server DB to address specific user needs. One application design uses PDA data presentation/capture (wired/wireless) for in-plant user interface. That product will use SQLite(?) on the PDA but a full client server DB on the "host" machine. So far a multi-user PDA has not been introduced :-) Fred
