Why do it this way? Why not write your own custom_sqlite3_exec(...) that uses the standard, stable, documented interfaces?
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. 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. 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. On Tue, 30 Jul 2019 at 07:40, Barone Ashura <bar0n3ash...@gmail.com> wrote: > I really wish to keep the argument polite and constructive, so please dont > get me wrong if I reply, I just want to understand what you are referring > to, realize and evaluate which is the best way to go for me, not for the > sqlite library, that's why I writing to the sqlite library. > > Il giorno mar 30 lug 2019 alle ore 15:50 Hick Gunter <h...@scigames.at> ha > scritto: > > > f) There are exactly 2 documented functions in your code. Did you not > read > > their documentation??? > > > > See https://sqlite.org/c3ref/column_blob.html > > > > " After a type conversion, the result of calling sqlite3_column_type() is > > undefined, though harmless. Future versions of SQLite may change the > > behavior of sqlite3_column_type() following a type conversion." > > > > which type conversion are you referring to? the second one erroneously > called in the example code? I do understand the 'type conversion' to be one > of the six functions listed in the page you linked (which was read). > The statement before the one you quoted specifically says: "The return > value of sqlite3_column_type() can be used to decide which of the first six > interface should be used to extract the column value". Isnt this exactly > what I want to be doing? Read the column type from the statement, according > to the return value call the relevant extraction function. The > documentation describes 'automatic conversions' being performed if I am > trying to extract a datatype that is different from the internal datatype. > But this is exactly what I want to stay away from, unless, of course I am > missing something, which I would very like understand. > > > > b) Breaking encapsulation includes referencing internal .h files in your > > own code. You should be using sqlite3.h *only* > > > > I am not referencing ANY internal.h file in my own code. I am just using > the amalgamation distribution, and I am writing code in sqlite.c, not in my > own source files, so nobody outside of sqlite.c calls any function or uses > any datatype that is not declared in sqlite.h. > > > > > You do realise that declared types are not enforced in SQLite? If somehow > > a real with a non-integer value got inserted into an integer field, the > > type of the returned value would still be real, but you would be > expecting > > integer. And silently reading the bits of the double value as an integer, > > which would probalby cause a practically untetectable error. > > > > True, agreed. This is the reason why the types of each value being inserted > into, updated and read from the database is strictly enforced outside of > sqlite. To state in a cear way: SQLite might not enforce declared types, by > the application around sqlite has been specifically designed to enforce > different types. > > > > > > c) There is no guarantee that the internal fields referring to a previous > > state of a Mem structure are preserved across conversions. > > > > why do you refer to a "previous state of a mem structure"? the code is > being executed inside a custom sqlite_exec function, which mirrors the > behaviour of the provided sqlite_exec function, except for the conversions > to/from text (which return the pointer to the internal data type, without > any conversion in case of Integer and float value), WAY before calling the > statement finalization. The callback itself that must be provided to > sql3_exec, is called before finalizing and freeing the memory allocated by > the statement execution. > > > > I do hope you are statically linking your modified SQLite code to your > > application and not installing it as a shared image. In the latter case, > > some unsuspecting application might inadvertently stumble across your > > version of the interface, which no longer conforms to the published > > interface, and cause failures there. That would probably cause some > really > > rave reviews. "I just installed XXX on my phone and it died" is not a > > viable recommendation. > > > > Again good point, but we are 'lucky' here as well... sqlite amalgamation is > compiled into the application and not dinamically linked. > > I know that what I am doing is hazardous, rings alarm bells, 'dirty' (if > you want to call it dirty), I know that it could be done in several > different ways, it's just that sqlite3_exec does already an excellent job > in wrapping prapared statemets, stepping and finalizing the statement > itself; it does return an array of stringified column values, and that's > what I would like to avoid (in the case of integers and floats). > > Looking forward to reading more insights, hints, tips, suggestions, > arguments, advice, whatever. > > Thanks > _______________________________________________ > sqlite-users mailing list > sqlite-users@mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
