You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Number_Of_Rows is not implemented in SQLite: this is acceptable because it is clearly expressed in the doc and it can be implemented with the reservations below.
Affected_Rows is not implemented correctly for SQLite: this is annoying because it's not expressed at all as Gnoga doc says: executes a SQL query and returns the number of rows affected, but affected_Rows calls sqlite3_total_changes() which only handles modifications (i.e. only INSERT, UPDATE or DELETE) and not the result of the query. A simple SELECT * table will return 0 even if the table is full to bursting. 2) Implementation has an impact on performance (see below).
Execute_Update is not implemented correctly for SQLite: since, after calling Execute_Query, we call Affected_Rows, we end up with the same problem.
8.2.2 Suggested corrections
Correcting these inconsistencies is not difficult, but the result will range from transparent to very slow (depending on the type of query and/or the volume of data returned, since the entire recordset have to be iterated).
Number_Of_Rows: As the name don't suggests, returns the number of rows in the recordset, not in the table. Can be implemented with the above reservations by iterating through the entire recordset.
Affected_Rows: you'll need to remember the last query performed by Execute_Update (in the connection record, next to UTF8_String). If this query contains INSERT, UPDATE or DELETE, we return the result unchanged; if it contains a SELECT |Column_Name, we transform it into a SELECT COUNT(|Column_Name). If the query contains anything else, we execute a standard Query with the above reservations, since we have to iterate through the entire recordset.
Suggested implementations
Two options:
Either I implement it at Gnoga level, but Pascal has to agree. It's an imperfect hack, but it'll be better than this unusable existing one. This is the preferred option to my taste.
Or I can implement this in v22 and ban the use of Execute_Query, Execute_Update, Number_Of_Rows in the docs in favor of functions with identical names but prefixed v22.Sql, which is pretty dirty and wouldn't solve the problem of these rogue functions in Gnoga.Server.Database.
The text was updated successfully, but these errors were encountered:
sowebio
changed the title
Compatibility with MySQL
Compatibility between MySQL and SQLite
Nov 26, 2023
sowebio
changed the title
Compatibility between MySQL and SQLite
Compatibility between MySQL and SQLite (missing API)
Nov 26, 2023
Problem description
Number_Of_Rows is not implemented in SQLite: this is acceptable because it is clearly expressed in the doc and it can be implemented with the reservations below.
Affected_Rows is not implemented correctly for SQLite: this is annoying because it's not expressed at all as Gnoga doc says: executes a SQL query and returns the number of rows affected, but affected_Rows calls sqlite3_total_changes() which only handles modifications (i.e. only INSERT, UPDATE or DELETE) and not the result of the query. A simple SELECT * table will return 0 even if the table is full to bursting. 2) Implementation has an impact on performance (see below).
Execute_Update is not implemented correctly for SQLite: since, after calling Execute_Query, we call Affected_Rows, we end up with the same problem.
8.2.2 Suggested corrections
Correcting these inconsistencies is not difficult, but the result will range from transparent to very slow (depending on the type of query and/or the volume of data returned, since the entire recordset have to be iterated).
Number_Of_Rows: As the name don't suggests, returns the number of rows in the recordset, not in the table. Can be implemented with the above reservations by iterating through the entire recordset.
Affected_Rows: you'll need to remember the last query performed by Execute_Update (in the connection record, next to UTF8_String). If this query contains INSERT, UPDATE or DELETE, we return the result unchanged; if it contains a SELECT |Column_Name, we transform it into a SELECT COUNT(|Column_Name). If the query contains anything else, we execute a standard Query with the above reservations, since we have to iterate through the entire recordset.
Suggested implementations
Two options:
Either I implement it at Gnoga level, but Pascal has to agree. It's an imperfect hack, but it'll be better than this unusable existing one. This is the preferred option to my taste.
Or I can implement this in v22 and ban the use of Execute_Query, Execute_Update, Number_Of_Rows in the docs in favor of functions with identical names but prefixed v22.Sql, which is pretty dirty and wouldn't solve the problem of these rogue functions in Gnoga.Server.Database.
The text was updated successfully, but these errors were encountered: