Hello,

on 11/18/2005 03:39 PM jonbouyw said the following:
>> I am experiencing a few glitches with the driver test script. Right
>> after trying to create tables for the articles and files tables the
>> script attempts to delete all the rows in those tables. However, it is
>> failing saying that the table does not exist. If I restart the
> script it
>> succeeds in deleting the rows . Do you have any idea regarding why
>> this happens?
>>
> No I have no idea why that happens.
>
> I'm am aware of it though, strangely it runs right through the test
> script, first time, when using a persistent connection without those
> problems. But it doesn't let go of the persistent connection to the
> resultant database. Which is probably related to the non persistent
> connection problem.
>
> It's strange though, even with a non-persistent connection, because
> after repeating the script a couple of times it works fine.

I figured that the problem is that when you change the schema of an
SQLite database, existing database connections are not made aware.

The driver test script may add tables for testing auto-increment and
BLOBs. The connection that tests these features is not aware right away.

The solution was to change the driver test script to close and reopen
the database connection after a schema change. It works now.


> Apologies, I would have replied sooner but I have spent the last few
> days in hospital.

Oh, I am sorry to hear. I hope you are well now.


>> Another matter, why do you touch the database file and test whether it
>> is readable and writable before creating the database file? Is it to
>> test whether you can write to the database file directory?
>>
>
> Yes it's just another layer to assure that file permissions are set
> (or can be set) correctly on the server, thereby giving the user a
> better clue why they are unable to create a database. It's just a
> habit I've got into with SQLite databases.

I think a single is_writable call to check whether the database
directory would be sufficient. Anyway, that is ok too.

I just added an option to set the file access mode. Setting to 0666 by
default is dangerous as it may make the database file easy to change or
steal by other users in an shared environment. I made the default 0640.
0600 would be safer but then the Web server may not be able to read the
file.

I also added support to use composite primary keys. The way you had
assumed that only the auto-increment field could be a primary key.


I will be documenting these changes soon. For now you can access the
latest version the MetaL CVS repository:

http://www.meta-language.net/download.html#cvs


--

Regards,
Manuel Lemos

Metastorage - Data object relational mapping layer generator
http://www.metastorage.net/

PHP Classes - Free ready to use OOP components written in PHP
http://www.phpclasses.org/