On Wed, 25 Aug 2004, D. Richard Hipp wrote:
Ara.T.Howard wrote:On Tue, 24 Aug 2004, D. Richard Hipp wrote:
The more people use SQLite version 3, the faster it will leave beta status....
in particular, which features would you say need tested? i have many uses for sqlite, perhaps i may be able to start using 3 for some of my projects.
All core features have been thoroughly tested. I'm looking for problems with the API. Do we need new parameters on some functions? Do we need to change the semantics of some functions? Do we need to change the semantics of some of the SQL.
Once the code comes out of beta, the API is frozen. Any deficiencies we'll just have to live with. So if there is anything you think needs to be added which cannot be added in a backwards compatible way, you need to speak up now.
Typically these kinds of problems are only discovered after heavy use, which is why I'm asking for more users before I move out of beta.
The question of Host Parameter Names and their format is the kind of thing that needs to be resolved now, before leaving beta. I just changed the parsing of Host Parameter Names (a.k.a. bind parameters) from ":NNN:" where NNN is a number to ":AAA" where AAA is any alphanumeric text. Those kind of changes need to be identified soon before the wrong implementation gets frozen into the design forever.
Thanks for your help.
i'll talk with jamis buck about this, he did the (most excellent) ruby binding to sqlite and i am now planning on using it heavily in a production system. however, the current binding is for 2.8 only. i'll speak with him about 3 and see if there is anything i can do to assist with that code (assuming he plans to do a version 3 binding) - which obviously would stress the api - and perhaps begin using it in some test clusters i am running via sqlite based code.
i'm curious, have many changes been made to the locking strategy which might affect concurent NFS usage? i've read the new docs, but have not had time to look at the source. for my usage i actually use an additional lock file to ensure that there can be exactly one writer to an sqlite database regardless of any byte range write locks it may use internally. my biggest issue to date has been to detect broken locks and i've developed a userland algorithim to do so and automatically clear them - useful for nfs work... anyhow, any tidbits regarding changes likely to affect nfs useage are appreciated...
also, in the docs you mention 'opening the directory and calling fysnc on it'. you mean the directory is opened for writing?
cheers.
-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| A flower falls, even though we love it;
| and a weed grows, even though we do not love it. | --Dogen
===============================================================================
