ANN: wxSQLite3 1.7.2 released Topic is solved

[utelle]

The new version 1.7.2 of wxSQLite3 - a thin wrapper for the SQLite database for wxWidgets applications - now supports the current version 3.3.12 of SQLite. The wxSQLite3 API is now independent of optional features; it can be checked at runtime for which optional features wxSQLite3 was compiled. Since on Linux support for loadable extensions is not compiled into SQLite by default it has been made optional in wxSQLite3 as well.

The wxSQLite3 file release contains the doxygen generated documentation. The file release for Windows additionally contains version 3.3.12 of the SQLite DLL in 3 different flavors:
- the original unmodified DLL,
- a DLL including support for accessing database meta data, and
- a DLL supporting optional database file encryption using 128 bit AES encryption.

Feedback is welcome.

Regards,

Ulrich

P.S.: SQLite 3.3.13 was released on Feb 13, 2007 - a bit too late for wxSQLite3 1.7.2.

P.P.S.: February 23, 2007: The online documentation of wxSQLite3 has been updated to version 1.7.2 after the SourceForge Project Shell Service is operational again at last.

[jb_coder]

Congratulations on the release!

Have you noticed any benefits or drawbacks to switching from the old sqlite3_prepare function to the new sqlite3_prepare_v2 function?

[utelle]

Congratulations on the release!

Thanks!

Have you noticed any benefits or drawbacks to switching from the old sqlite3_prepare function to the new sqlite3_prepare_v2 function?

As said in the SQLite documentation sqlite3_prepare_v2 is recommended for all new programs.

I have not detected any drawbacks yet (except that wxSQLite3 now requires SQLite 3.3.9 or higher).

But there are certainly benefits: One will experience SQLITE_SCHEMA errors less frequently since the new interface will automatically retry the SQL query/statement. Only if the schema has changed in a way that makes the statement invalid, SQLITE_SCHEMA error will be returned signaling now a fatal error (that is calling sqlite3_prepare_v2 again will not make the error go away).

Regards,

Ulrich

[jb_coder]

You can support versions earlier than 3.3.9 with something like

Code: Select all

#if SQLITE_VERSION_NUMBER>=3003009
        int rc = sqlite3_prepare_v2((sqlite3*) m_db, sql, -1, &stmt, &tail);
#else
        int rc = sqlite3_prepare((sqlite3*) m_db, sql, -1, &stmt, &tail);
#endif

The main reason that I was concerned about upgrading to the v2 version of the function was so many releases of SQLite immediately following the 3.3.9 release with release notes like "still hammering out issues with sqlite3_prepare_v2". It looks like they've fixed those issues, but I wanted to get your advice before putting the change in DatabaseLayer.

Thanks!

[utelle]

You can support versions earlier than 3.3.9 with something like

Code: Select all

#if SQLITE_VERSION_NUMBER>=3003009
        int rc = sqlite3_prepare_v2((sqlite3*) m_db, sql, -1, &stmt, &tail);
#else
        int rc = sqlite3_prepare((sqlite3*) m_db, sql, -1, &stmt, &tail);
#endif

I thought about using something like that, too. But in my opinion it doesn't make much sense. If someone uses a specific release of wxSQLite3 which includes the required sqlite3.h header file resulting in always using sqlite3_prepare_v2. One would have to exchange the sqlite3.h header file accordingly.

Another option would be to check for the availabilty of sqlite3_prepare_v2 at run time, but that would only be feasible if SQLite is loaded dynamically without using a link library.

A real problem with SQLite is that it is not possible to find out at runtime which features were compiled in and which were omitted.

The main reason that I was concerned about upgrading to the v2 version of the function was so many releases of SQLite immediately following the 3.3.9 release with release notes like "still hammering out issues with sqlite3_prepare_v2". It looks like they've fixed those issues, but I wanted to get your advice before putting the change in DatabaseLayer.

Guess, why I didn't jump on version 3.3.9.

In fact I don't fully understand the rules how and when it is decided to release a new SQLite version.

Version 3.3.11 should have been quite stable in respect to the new interface, but the release was totally flawed, in fact is was almost identical to 3.3.10, but only accidentally.

Version 3.3.12 could have been named 3.3.11 but that would have added more confusion.

The current version 3.3.13 fixes some (subtle) bugs and adds a few features like additional SQL operators or functions. The API is not affected, so wxSQLite3 is completely compatible with version 3.3.13.

I think you may dare to switch over to sqlite3_prepare_v2 in DatabaseLayer.

BTW, have you ever thought about implementing loadable database drivers for DatabaseLayer? Currently you have to decide at compile time which database interface is used. For some applications it would be nice to decide at run time which database interface should be used.

Regards,

Ulrich

[jb_coder]

Having SQLITE_VERSION_NUMBER blocks is useful if you use the version of SQLite that ships with your system. For example suse 10.2 ships with SQLite 3.3.8 in an RPM. If a user wants to use software dependent on wxSQLite3 or DatabaseLayer, it's helpful if they only have to worry about compiling the component rather than downloading and compiling the latest SQLite library as well.

The main reason that I haven't gone to a "plug-in" based DatabaseLayer is that I haven't had much luck with module based components in the past. I agree though that it would be good to move to more runtime-based decisions.

[utelle]

Having SQLITE_VERSION_NUMBER blocks is useful if you use the version of SQLite that ships with your system. For example suse 10.2 ships with SQLite 3.3.8 in an RPM. If a user wants to use software dependent on wxSQLite3 or DatabaseLayer, it's helpful if they only have to worry about compiling the component rather than downloading and compiling the latest SQLite library as well.

This might work on Linux like systems since there is a "standard" way of installing SQLite. On Windows it's different. Therefore wxSQLite3 includes all needed files for building on Windows. The consequence is that one would have to exchange for example at least the sqlite3.h header file before building wxSQLite3 if it's planned to use an older version of SQLite.

Additionally a new version of SQLite quite often meant new features. When I upgraded wxSQlite3 to support a newer version of SQLite in those cases the wxSQLite3 API often changed, too. So, I'd recommend, if one needs to support an older SQLite version the corresponding wxSQLite3 version should be used. In general upgrading to the current SQLite version would be the better option.

The main reason that I haven't gone to a "plug-in" based DatabaseLayer is that I haven't had much luck with module based components in the past. I agree though that it would be good to move to more runtime-based decisions.

You're right module based components have their drawbacks especially if they are implemented in C++. One would probably need a different binary for each supported compiler. Nevertheless I would like to have such drop-in database layer modules.

Regards,

Ulrich