Sounds like a fast way to store a ton of preferences. I think I
remembered in our old discussions about it that sqlite was fast enough
that the Pd object didn't need to be threaded, which is nice.
I think the code would be a lot easier to read if the classes where
broken out into separate files. This is the standard way to do with
externals: one class per file. Then it would be possible to also
compile each class as a separate .pd_darwin, or compile it like you
have now.
.hc
On Mar 1, 2009, at 2:10 PM, Mike McGonagle wrote:
Hello all,
I would like to announce the release of SQLite3db.
This release represents a complete rewrite of the externals. It has been rolled into a single external library containing the externals [sqlite3db], [sqlite3query], [sqlite3rowid], and [sqlite3blob].
This release includes several features:
Database can be on disk or an in-memory database.
The [sqlite3query] object now supports Place Holders.
Comprehensive error reporting.
Includes a separate object for retrieving the ID for the last
record inserted (allows making links between tables)
- SSSAD plug-and-play panel for storing multiple sets of SSSAD
parameters.
You can get the archive for files at:
http://puredata.info/Members/mjmogo/SQLite3db_v0_03.zip/view
Also, the 'makefile' only contains a process for making a 'pd_darwin' external for the Mac. It should not be difficult to compile for Unix or Windows, as it is Ansi-C. Everything should work with Vanilla Pd as well.
Let me know if you have any suggestions, criticism, or general
praises ;)Mike
--
Jean-Luc Godard - "To be or not to be. That's not really a question."
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
¡El pueblo unido jamás será vencido!