https://bugs.kde.org/show_bug.cgi?id=420599
--- Comment #7 from Jarosław Staniek <stan...@kde.org> ---
> When i open the query from the attached database, using Kexi 3.2 or 3.3,
> in text view it is true that the displayed SQL remains unchanged, as you
> said, but when switching to data view all the rows have a value of 'group',
> even though the source table, the one with the "group" column, has only
> integers; design view the expression under “query columns” is now “expr1:
> 'group'”.
KEXI Query plugin tries to avoid modifications if it's possible or easy.
WHen SQL view is open directly, no SQL is altered.
If the design view is used, sometimes alias is added (this is a feature of KDb)
in order to have clearly named all columns. There's such case when we use
constants or in general, expressions, instead of column names in the "FROM" SQL
section.
This is all still KDBSQL dialect we're within. Native dialects are touched only
when data view is involved, so - as expected - in a lazy manner.
> Moreover, if i make any change to the query in design mode, for example
> toggling twice the visible check box, and *then* switch to text view
> without saving the query, it changes again to SELECT 'group' AS expr1 FROM
> source.
This is a quality of round-tripping between these two views and can be always
improved. I remember a lot of code and states being added to achieve as small
changes as possible.
> If i am not mistaken, it means that KDbNativeStatementBuilder generated a
> statement with the column quoted as "group" straight from the KDbQuerySchema,
> but KDbParser reads it as if it were:
There's string (\'{e_str1}*\'|\"{e_str2}*\") in the parser; type of quotes are
unimportant. Double quotes are never meant to be column names (unlike in some
SQL dialects) and for 2 more reason this would stay as is: 1. compatibility
with prev. KEXIs and MS Access, 2. "group" really looks like a string literal.
> Thus, even if KDbParser could read columns quoted [as this], unless
> KDbNativeStatementBuilder used [ and ] as quote characters, the problem would
> still be there, wouldn’t it?
When the #332161 is implemented, KDbNativeStatementBuilder shall support [foo]
the way it's designed in #332161, that is, first attempt is to locate
identifier foo and if it fails, foo is meant to be a query parameter.
--
You are receiving this mail because:
You are watching all bug changes.
