[libsql] libsql 0.63 released

[<re...@du...>]

Hi,

I've released libsql 0.63. Been working on memory leaking issues and 
resultset freeing.

regards,

rene

=======================================

changes in 0.63
* Hunting memory leaks. I believe they are all solved now
* Made TResultSet usage (especially freeing) more proof

Here is code of allowed methods of querying and result set usage:
   //test main constructor / destructor:
   db := TLiteDB.Create(nil, ':memory:');
   db.Free;

   //basic query on DB
   db := TLiteDB.Create(nil, ':memory:');
   db.FormatQuery('select %d+%d', [1,1]);
   db.Free;

   //basic formatquery on DB
   db := TLiteDB.Create(nil, ':memory:');
   db.FormatQuery('select %d+%d', [1,1]);
   writeln (db.Results[0][0]);
   db.Free;

   //Per row fetching using execute method using DB
   db := TLiteDB.Create(nil, ':memory:');
   h := db.Execute ('select 1+1');
   while db.FetchRow(h, row) do
     writeln (row[0]);
   db.FreeResult(h);
   db.Free;

   //Per row fetching using formatexecute method using DB
   db := TLiteDB.Create(nil, ':memory:');
   h := db.FormatExecute ('select %d + %d', [1, 1]);
   while db.FetchRow(h, row) do
     writeln (row[0]);
   db.FreeResult(h);
   db.Free;

   //Result set testing:
   db := TLiteDB.Create(nil, ':memory:');
   rs := db.UseResultSet('testing');
   rs.Query('select 1+1');
   writeln (rs.Row[0][0]);
   db.Free; //db should free the result set

   db := TLiteDB.Create(nil, ':memory:');
   rs := db.UseResultSet('testing');
   rs.Query('select 1+1');
   writeln (rs.Row[0][0]);
   rs.Free; //db should not complain about resultset being freed
   db.Free;

   db := TLiteDB.Create(nil, ':memory:');
   rs := TResultSet.Create(db);
   rs.Query('select 1+1');
   writeln (rs.Row[0][0]);
   db.Free; //db does _not_ free the result set since it was manually 
created
   rs.Free;

   db := TLiteDB.Create(nil, ':memory:');
   rs := TResultSet.Create(db);
   rs.FormatQuery('select %d + %d', [1,1]);
   writeln (rs.Row[0][0]);
   db.Free;

   //double usage of resultset
   db := TLiteDB.Create(nil, ':memory:');
   db.UseResultSet(rs);
   rs.FormatQuery('select %d + %d', [1,1]);
   writeln (rs.Row[0][0]);
   db.Free;
   rs.Free;

   //row fetching using a TResultSet
   db := TLiteDB.Create(nil, ':memory:');
   rs := db.UseResultSet('rowfetch');
   if rs.Execute ('select 1+1') then
     while rs.FetchRow do
       writeln (rs.Fetched[0]);
   rs.FreeResult;
   db.Free;



changes in 0.62
* sqlite was performing an 'unlock' in Rollback[transaction] (Dak?)
* base class (mysql/odbc) still had locks on database transactions. 
Removed. Mysql/odbc users beware, starting/comitting/rollback a 
transaction no longer locks the thread. You will have to lock/unlock 
threads using respective methods yourself.
* added constant LibSQLVersion (String type, now: '0.62') in base class. 
(Dak)
* DateTime support in TResultCell
* Added prorperty ValidValue to a resultcell to differate between db 
results and 'out-of-range' or nen-existent result.
* Added method 'FieldExists' to TResultRow to determinate a particulair 
field name exists.
* OnClose handler for sqlite
* Fixed reference counting bug in sqlite (multiple instances accessing 
the same database)
* Added method 'RefreshDBInfo' that calls FillDBInfo
* Added private 'AutoFree' varibale to TResultSet. Freeing a DB will not 
automatically free all associated resultsets that were created 
'stand-alone', (calling "DB := TnnnDB.Create(); rs := 
TResultSet.Create(DB); DB.Free; rs.free", in this order, could result in 
a AV error due to double freeing.).
* Added package file for convenience.
* Renamed all occurences of 'Owner' in TResultSet to 'SQLDB' to make 
things same more clear.




changes in 0.61
*Implemented virtual implementations in base class of some newly added 
methods for sqlite and/or mysql. ODBC class did not make any 
implementation of this virtual (and abstract) class. Possibly having 
unimplemented abstract classes leads to conflicts on some compilers 
(kylix, freepascal?).
*No other changes since 0.60

changes in 0.60

This happen to be "stable" version. On my system. No guarantees.
* The SQLITE transaction mechanism has changed a little. A transaction 
no longer involves an obliged thread lock. Threads can share the same 
file handle safely on windows systems.
* Removed a confusing property from the TResultSet class.
* Merged more support functions by PChev: flush, truncate, lock, vacuum. 
Tx!
* SQLite best tested currently. MySQL support without real problems. 
Most recent libmysql.dll ( version 5.0.n) supported.
* The components may use some attention. So does the documentation. 
Volunteer welcome!
* It is not multi-platform tested. Notify me of new issues please. Not 
much changes since last testing.
* Next release will contain additional sqlite class that provides a 
threading mechanism to allow multiple threads on some unix systems 
redirected to a single thread for the file system to work correctly.
* Some minor bug fixes.

changes in 0.57
* formatquery adjustments - floating point issues
* result set freeing (fixes shutdown error)

changes in 0.56
* result set usage, issues

Changes in 0.55
* added delphi4 compatability to sqlite units
* improved result set usage
* speeded up resultset lookup some
* some bugfixes and issues
* fixed execute/fetchrow functionality for sqlite 3
* added execute/fetchrow functionality to TResultSet (!)
* TResultset has extra property: Fetched

0.55 is release candidate for 0.60. This time i really do not plan 
additions to functionality.
0.55 seems relative stable to me, all functionality is ok. what bothers 
me a tiny bit is that resulset handling has got a little more complex.
The db class keeps track of used result sets. Things may both speed up 
and get little more complex if we skip that functionality.
TResultSet has now almost all methods that originally were found in db. 
While both ways will work, there are now many ways how to perform a query.
however, i think i favourize giving TResultSet a central (obliged?) 
place.But doing so, would remove 'ease-of-use' of the db component itself.
Anyhow, stuff is working ok, it is nicely put together, i don't see any 
major mistakes but as said, complexity of code may make things less 
maintainable.