Edit: You may want to actually time different solutions to see which one works the fastest in your target environment. The last version makes every process wait for the winner of BEGIN IMMEDIATE, who then goes on to create and populate the table. If you want to avoid executing the code unless the table already exists: This has the benefit of making any other process wait until the first one is finished. To make sure only one process actually does the work, use a transaction: Is this a critical change? Of course not! It just seems that a lot of information was left out of the extended result codes that could have (and should have) been included.Īny process running that sequence will be sure that the table exists and the default records (as identified by the primary key) are there, regardless of which process does what. Code should not have to examine messages intended for human consumption the extended result code should convey as much information as possible. It is my belief, perhaps not in agreement with the SQLite3 maintainers, that a primary purpose of Extended Result Codes should be to give callers of the API the ability to get more information about the nature of the error. Checking with a PRAGMA whether the table exits adds an extra SQL call, which likely to be even more costly (though perhaps more reliable shoud errmsg() change) than analyzing the errmsg string. This code will be in a heavy usage area so I want to minimize the number of SQL statements executed. ![]() If a failing create returned SQLITE_ERROR_ALREADY_EXISTS instead of SQLITE_ERROR, then I would not have to do ANY extra SQL. If it doesn't exist, I want to create it and then add some default rows before adding real data rows). Use case: If the table already exists, I want to do nothing else before adding real data rows to it. (No, CREATE TABLE IF NOT EXISTS won't help me in this case unless there is a way that I can determine whether it succeeded due to actually creating the table or due to the table already existing.)Īlso, I would rather not add any extra SQL execution to distinguish the results: instead the C API should tell me. (2) Why aren't commonly encountered SQLITE_ERROR codes like this broken down into extended codes? (1) What is the best way to distinguish CREATE TABLE failing due to ALREADY EXISTS from other possible failures? This seems like the perfect opportunity for using an Extended Result Code such as SQLITE_ERROR_ALREADY_EXISTS but there is no such extended result code. ![]() The message might get reworded or translated into another language! I have learned from experience, however, that it is a usually bad idea for a program to depend upon the wording of an error message intended for human consumption. Is there any good way to distinguish CREATE TABLE failure due to table already exists from other possible failures? The cleanest I have found is to compare the string returned by sqlite3_errmsg(.) with the text "table.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |