[KEXI] [Bug 332161] Add support for identifiers with special characters or equal to reserved words in queries

jordi fita i mas bugzilla_noreply at kde.org
Wed Apr 29 16:20:50 BST 2020


https://bugs.kde.org/show_bug.cgi?id=332161

jordi fita i mas <jfita at infoblitz.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jfita at infoblitz.com

--- Comment #7 from jordi fita i mas <jfita at infoblitz.com> ---
This comment is just to see whether i understood the change proposed in this
report.

Let's say we have a table with the terrible name of “table” and two columns,
“id” and “integer”, to make things difficult, and want to filter this table by
the “integer” column using some criteria.

If i understood all the comments correctly, the native KDbSQL statement, the
string that someone using KDbParser::parse(KDbEscapedString) to get a
KDbQuerySchema would need to write, should be: 

    SELECT id, `integer` FROM `table` WHERE `integer` = [some criteria]

This is also the string that Kexi would store in kexi__objectdata for that
query, regardless of whether it was generated with the designer or in the text
editor. What you call the “internal format”.

However, you do not want Kexi users to see that string and, to make it look
more like an Access’ query i imagine, when switching to text view it should be
shown like this instead:

    SELECT id, [integer] FROM [table] WHERE [integer] = [[some criteria]]

Let's call this the “external format” and, as i understand, it is merely a
“cosmetic” query, as it were, because the actual query that KDb should parse
and convert to the driver-native SQL is the first, the one stored in
kexi__objectdata using the internal format.

Kexi, somehow, should transform from internal format to the external when
switching *to* text view and convert back to internal when switching *from*
text. However, in comment 3 you said:

> Conversions should happen in KDb's routines where KDbQuerySchema instances are
> stored/retrieved. The routines can be exposed in KDb's Utils API for engineers who
> wish to use the internal format.

I may be completely wrong here, but that seems to imply that the conversion
between internal and external formats should be done in
KDbConnection::storeObjectData and KDbConnection::loadObjectData. But these
functions are *not* called from Kexi’s query plugin, as far as i can see: it
uses storeDataBlock/loadDataBlock with the query as a string.

The other possibility is that the format transformation is in KDbParser and
KDbNativeStatementBuilder, the classes that Kexi use to convert the SQL string
to KDbQuerySchema and back to string.  This option would mean no need to change
Kexi’s code, but then i do not see what the internal format gives us.

I am no trying to say that the internal format is useless, just that i do not
see it yet. If you could, please, clarify where this conversion would be
perhaps i would understand it  better. Thank you :)

Finally, regarding the desire to keep queries to look like MSA as much as
possible, is the change for criteria grammar from [this] to [[this]] much
better than changing columns references from [this] to `this`?

What i mean is that, assuming KDb would only quote columns when strictly
necessary, people will see parameters more often than quoted columns in the SQL
generated by Kexi.

It seems, though, that in all probability you had another use case here that i
can not see. I would appreciate if you could also explain this a bit more.


Sorry about the rumbling.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the Kexi-bugs mailing list