ANN: wxSQLite3 1.7.2 released Topic is solved

Do you like to promote your wxWidgets based application or component!? Post it here and let's see what the critics have to say. Also, if you found that ONE wx component the world needs to know about, put it here for future reference.
Post Reply
utelle
Moderator
Moderator
Posts: 919
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

ANN: wxSQLite3 1.7.2 released

Post by utelle » Tue Feb 13, 2007 5:49 pm

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.
Last edited by utelle on Fri Feb 23, 2007 9:08 pm, edited 2 times in total.

jb_coder
Super wx Problem Solver
Super wx Problem Solver
Posts: 267
Joined: Mon Oct 18, 2004 10:55 am

Post by jb_coder » Wed Feb 14, 2007 12:01 pm

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
Moderator
Moderator
Posts: 919
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Post by utelle » Wed Feb 14, 2007 1:35 pm

jb_coder wrote:Congratulations on the release!
Thanks! :)
jb_coder wrote: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
Super wx Problem Solver
Super wx Problem Solver
Posts: 267
Joined: Mon Oct 18, 2004 10:55 am

Post by jb_coder » Wed Feb 14, 2007 2:29 pm

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
Moderator
Moderator
Posts: 919
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Post by utelle » Wed Feb 14, 2007 3:22 pm

jb_coder wrote: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.
jb_coder wrote: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. :wink:

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
Super wx Problem Solver
Super wx Problem Solver
Posts: 267
Joined: Mon Oct 18, 2004 10:55 am

Post by jb_coder » Wed Feb 14, 2007 11:00 pm

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
Moderator
Moderator
Posts: 919
Joined: Tue Jul 05, 2005 10:00 pm
Location: Cologne, Germany
Contact:

Post by utelle » Fri Feb 16, 2007 4:48 pm

jb_coder wrote: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.
jb_coder wrote: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

Post Reply