https://bugs.kde.org/show_bug.cgi?id=420599
--- Comment #5 from Jarosław Staniek <stan...@kde.org> ---
The SQL string in kexi__objectdata is in KDBSQL dialect. This makes the KEXI
format backend independent and the database content can be migrated without any
change e.g. from a file to a server. I am sorry - it must be too deeply hidden
behind the mask.
So that string, when retrieved from kexi__objectdata, is displayed as-is in the
SQL view of KEXI because it's assumed to be the portable KDBSQL dialect. (Well,
in recent KEXIs (>=3.0 probably) it's actually parsed to check validity and if
we're switched from the visual editor, it's formatted as well).
> One source of confusion is that i dot know if the “native” in
> KDbNativeStatementBuilder refers
> to driver-native or KDbSql-native statement.
In KexiQueryDesignerGuiEditor::storeLayout() there's
KDbNativeStatementBuilder builder(conn, KDb::KDbEscaping);
This means that we store the KDbSql-native statements. The
generateSelectStatement() has null driver in the logic everywhere in this case.
I admit the KDbNativeStatementBuilder class name can be confusing in a way that
it serves both native SQLs and the KDBSQL. Original purpose was for the native
only but then it was soon apparent that large portions of code are common for
KDBSQL and native SQLs.
KDbNativeStatementBuilder started as an internal class but now in >=3.1 it's a
public API. Therefore renaming to a better name, maybe KDbStatementBuilder, is
not possible :)
> Using [] to escape identifiers would free the double quotes to be used only
> for string literals, but
> it seems to me that KDbNativeStatementBuilder, or KDB::escapeIdentifier,
> should still be corrected to
> use the proper KDbSql escape characters.
Is this still the case given what I said above?
--
You are receiving this mail because:
You are watching all bug changes.
