> Why do it this way?
Why not write your own custom_sqlite3_exec(...) that uses the standard, > stable, documented interfaces? Because sometimes I take wrong turns despite my best intentions :) But I usually smell it, when I am taking wrong turns, and that is why I can up here asking for advice, insights and enlightment, so I can u-turn, go back at the crossroads, and take another direction :) > custom_sqlite3_exec(...) could call prepare / step / finalize, and use the > standard sqlite3_column_* interfaces to fill a result array. This would be > very little work and could be a drop in replacement of sqlite3_exec. As a > bonus, you can have a proper signature of void* for your callback function > (since it's no longer receiving an array of strings, char** is a lie which > will confuse anyone working on the project in future). Another > maintainability bonus: The name will alert any consumers that this isn't > part of the standard sqlite3 interface. > defining a new callback was one of the option for further development. The different typed callback would certainly be void* for the reason you mentioned. > An assumption you've made may be incorrect: You say that callers know what > data type to expect so that they know how to cast the results (I assume > this is based on the declared column affinity?), but SQLite is not a > strictly typed database. So the actual data might not match what they're > expecting; by going the route you've chosen the exact way you pick up these > errors might be quite far from the source of the error. > This is the thing that I need to get a perfect hold of. When could it happen that 'data might not match what they're expecting'. A small description of the application context and where and how SQLite kicks in. The usage of SQLite is completely wrapped into functions specific for each query being designed and executed, and data from query is returned in typed structures to the callers. Callers are ALWAYS local to the application domain, and there is no possibility (except in the case of poor programming and security, which can always be) for the users (either application users or 'library' users) to try and execute a custom written SQL statement. The make a long story short, I am developing the full stack of datatypes (C structs and/or c++ classes), functions, queries and their middle function calls that define which services are available to access data contained in our SQLITE database. I will try to place here a simple example, supposing we have a simple table as the following: CREATE TABLE VALUES ( id INTEGER PRIMARY KEY ASC, value_int INTEGER, value_double REAL, value_text TEXT, ); and that I want to execute the following simple query: SELECT * FROM VALUES; For this very specific query, are there circumstances where the call to sqlite3_column_type, for column 'value_int', returns a result different from SQLITE_INTEGER, and/or the union located at the base address of Mem returned by columnMem, is being filled as double or even worse, the whole Mem structure is filled as 'TEXT'? (We can rotate the question for the 3 value_XXX fields). Usage of SQLITE functions or casts in the queried results could very likely tamper with the 'expected' datatype. Is this one case case where the assumption is incorrect? > A sane improvement to the interface would be for the consumer of > custom_sqlite3_exec(...) to pass in an array of types that they are > expecting; checking that the types match inside of your custom function > would be fairly trivial (and performant) and you could have properly > defined behaviour for what happens if the types from the database don't > match the exepcted types. Some ideas are: Use SQLite type coercion (just > call sqlite3_int even if it's a string); fail; or skip the record. > Suggestion Acknowledged :) _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
