[KReport] [Bug 420774] New: Library shows error messages by itself and quits the application when it can not find its resource files
https://bugs.kde.org/show_bug.cgi?id=420774 Bug ID: 420774 Summary: Library shows error messages by itself and quits the application when it can not find its resource files Product: KReport Version: 3.2.0 Beta Platform: Compiled Sources OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: stan...@kde.org Reporter: jf...@infoblitz.com Target Milestone: --- SUMMARY I am trying to use KReport from a QML application. That application fetches the report layouts from a PostgreSQL and just needs to print the report, thus it does not use any of the designer features — layouts are designed in an external application, Kexi for now — but, the first time i try to call KReportPreRenderer.setDocument, the library complains that it can not find the resources for its icons. The error is the following: > Could not open icon resource file "kreport_breeze.rcc". > Application will not start. Please check if it is properly installed. That, by itself, is a mild annoyance; the problem is that the library decides to popup a KMessageBox without giving any chance to the application to display that error in its usual way — using QML controls in this case. Worse still, after the KMessageBox it calls qFatal, effectively calling std::abort, and terminates the application. In my opinion, the library has not enough context to known whether the error is fatal or no — for instance, in my case it does not matter whether the icons are loaded — and should let the application handle the error. In the case of Kexi it might be OK to abort, but as a general library it may be not. This report is to see if you agree that the library should not behave like this and, if you do agree, start discussions for a different design. I do not have any proposal because it is a bit hard to reach the application from where the error occurs. It seems that it is in the constructor of KReportPluginManager, instantiated by KReportPluginManagerSingleton the first time someone — KReportPreRenderer in my case— tries to use the plugin. Short of with an exception, right now i do not see how i can receive the error message…. Do you have any thoughts on this? What is the usual error reporting mechanism for KDE libraries? Thank you. SOFTWARE/OS VERSIONS Linux/KDE Plasma: openSUSE 15.1 KDE Plasma Version: N/A KDE Frameworks Version: 5.69.0 Qt Version: 5.12.2 -- You are receiving this mail because: You are watching all bug changes.
[KEXI] [Bug 332161] Add support for identifiers with special characters or equal to reserved words in queries
https://bugs.kde.org/show_bug.cgi?id=332161 jordi fita i mas changed: What|Removed |Added CC||jf...@infoblitz.com --- Comment #7 from jordi fita i mas --- 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 watching all bug changes.
[KDb] [Bug 420599] KDbNativeStatementBuilder escapes identifiers in a way that KDbParser parses as string literals
https://bugs.kde.org/show_bug.cgi?id=420599 --- Comment #6 from jordi fita i mas --- >> 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? I believe it is, yes. 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'”. 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. Checking with sqlite3 the value stored in kexi__objectdata, it outputs: > sqlite> select * from kexi__objectdata where o_sub_id = 'sql'; > 2|SELECT "group" FROM source|sql > sqlite> 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: SELECT 'group' AS expr1 FROM source 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? Sorry if a am not making any sense; i must not understand something from KDb internals :) -- You are receiving this mail because: You are watching all bug changes.
[KDb] [Bug 420599] KDbNativeStatementBuilder escapes identifiers in a way that KDbParser parses as string literals
https://bugs.kde.org/show_bug.cgi?id=420599 --- Comment #4 from jordi fita i mas --- Sorry if i misunderstood it, but from your comment that says > This time I am unsure it applies here. See #376052 and particular solution at > https://bugs.kde.org/show_bug.cgi?id=376052#c2. it seems like you are talking about the conversion from KDbSQL dialect to the driver’s dialect. That works as expected because, as you noted, the query SELECT group FROM source does indeed produce the expected result. However, what i am reporting is a problem with the SQL that Kexi stores in its kexi__objectdata table for queries. In fact, i did not write the SQL query in the attached file; i only used the designer mode and switched to text view just to debug, as it were, the results. My understanding is that KexiQueryDesignerGuiEditor uses a KDbQueryScheme to build the SELECT query without resorting to string manipulations, but when it is time to save the query and serialize it into kexi__objectdata uses a KDbNativeStatementBuilder to create the SQL string. KDbNativeStatementBuilder calls KDb::escapeIdentifier to escape, if needed, field and table names and, in this case, recognizes the group column as a SQL keyword and escapes it as "group" — KDb::escapeIdentifier always uses double quote. Then, to load the query in data mode, Kexi reads the serialized SQL from kexi__objectdata with KDbParser that recognizes "group" as the string literal 'group' instead of a column name. Afterwards, this query is converted to the driver-specific dialect, but at that moment it is too late and the column is now an anonymous literal. One source of confusion is that i dot know if the “native” in KDbNativeStatementBuilder refers to driver-native or KDbSql-native statement. If the former, the problem is from Kexi and not KDb, but then KDbNativeStatementBuilder should use KDbConnection::escapeIdentifier instead of KDb::escapeIdentifier. If the latter, KDbNativeStatementBuilder should build its statements in a way that KDbParser should be able read correctly. > This should work > > SELECT [group] FROM source > > once this wish is implemented: https://bugs.kde.org/show_bug.cgi?id=332161 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. Again, sorry if i misunderstood your response. -- You are receiving this mail because: You are watching all bug changes.
[KDb] [Bug 420599] New: KDbNativeStatementBuilder escapes identifiers in a way that KDbParser parses as string literals
https://bugs.kde.org/show_bug.cgi?id=420599
Bug ID: 420599
Summary: KDbNativeStatementBuilder escapes identifiers in a way
that KDbParser parses as string literals
Product: KDb
Version: 3.2.0
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: General
Assignee: stan...@kde.org
Reporter: jf...@infoblitz.com
Target Milestone: ---
Created attachment 127876
--> https://bugs.kde.org/attachment.cgi?id=127876&action=edit
Database with a table using SQL keywords as column names and a query showing
incorrect results
SUMMARY
This is a problem for KEXI when building a query based on a table that has
columns named after SQL reserved keywords (e.g., “group”).
STEPS TO REPRODUCE (IN KEXI 3.2.1)
1. Create a table with a column named “group”; it does not matter its type or
whether its primary key or not.
2. Insert any data that column, but avoid “group” as value.
3. Create a new query with only the “group” column from that table.
4. Switch to SQL view and check that the SQL is indeed correct, with group
double quoted.
5. Switch to data view
6. Switch back to SQL view
OBSERVED RESULT
In data view, all rows have the literal string “group” as value of a column
named “expr1”.
In the second switch to SQL, the query has changed from
SELECT "group" FROM source
To
SELECT 'group' AS expr1 FROM source
In the attached database file the SQL query does not changed because it was
saved before switching view, but in data mode it still shows all rows with the
same incorrect literal string.
EXPECTED RESULT
In data view, the column should be named “group” and all its values should be
the same as in the source table.
In SQL, the query should still have the “group” column double quoted and
without any alias.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: openSUSE 15.1
KDE Plasma Version: N/A
KDE Frameworks Version: 5.69.0
Qt Version: 5.12.2
ADDITIONAL INFORMATION
This seems to be a side effect of bug #364950 (SQL: Handle escape sequences in
string literals), in where the parser was changed to parse double-quoted
strings as literals in order to recognize escape sequences in them.
As a quick test, i modified KDbSqlScanner.l from
e_str1 (\\\'|\'\'|[^'])
e_str2 (\\\"|\"\"|[^"])
string (\'{e_str1}*\'|\"{e_str2}*\")
to
e_str1 (\\\'|\'\'|[^'])
e_str2 (\\\"|\"\"|[^"])
string (\'{e_str1}*\')
quoted_identifier (\"{e_str2}*\")
plus a new quoted_identifier block, and then KEXI produced the expected result.
I am not sure if this is a but of KDb per se; maybe KEXI is just using the
wrong components to generate the SQL. Any thoughts on this?
--
You are receiving this mail because:
You are watching all bug changes.
[KEXI] [Bug 420534] New: Report uses incorrect record/row in group footer
https://bugs.kde.org/show_bug.cgi?id=420534
Bug ID: 420534
Summary: Report uses incorrect record/row in group footer
Product: KEXI
Version: 3.2.0
Platform: Compiled Sources
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Reports and Printouts
Assignee: kexi-b...@kde.org
Reporter: jf...@infoblitz.com
CC: a...@piggz.co.uk, in...@fables.co.za
Target Milestone: ---
Created attachment 127843
--> https://bugs.kde.org/attachment.cgi?id=127843&action=edit
Sample KEXI database with a table and a report based of on that table, with a
group using the first column that shows different values in header and footer
of same group.
SUMMARY
I believe this is actually a bug in KDb, but it is most visible when doing a
report that has data sourced fields in a group footer: when there is a single
group the QVariant returned by KexiDBReportDataSource is invalid; when there is
more than one group it uses the first row of the next group.
STEPS TO REPRODUCE
1. Create a new file-based KEXI project.
2. Add a new table with two fields, it does not matter their data type.
3. Add some rows to that table and repeat some values in one of the two
columns.
4. Add a new report with a section grouped by the column that has repeated
values; mark at least the “Show group footer” option.
5. Add a field in the group header and set its data source to the field for
grouping.
6. Add the same field but on the group footer.
6. Switch to edit mode.
OBSERVED RESULT
The fields in the header and footer of *the same group* do not have the same
values, in fact the footer has the same value as the header for the *next*
group; the last group’s footer has no value.
EXPECTED RESULT
The header and footer fields should have the same value because they are in the
same group and use the grouping field as data source.
(I’ve attached a sample database that shows this behavior).
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: openSUSE Leap 15.2
KDE Plasma Version: N/A
KDE Frameworks Version: 5.69.0
Qt Version: 5.12.2
ADDITIONAL INFORMATION
Is i said, i believe that i narrowed the problem down to KDb, but i do not know
how to fix it.
This is what i found.
In KReportPreRenderePrivate::renderDetailSection, KReport does something along
the lines of (pseudocode):
dataSource->moveFirst();
if (group->hasHeader()) {
renderSection(group->header());
}
while (!dataSource->eof()) {
renderSection(group->detail());
dataSource->moveNext();
}
if (group->hasFooter()) {
if (dataSource->movePrevious()) {
renderSection(group->footer());
}
}
The problem is that dataSource->movePrevious() returns true but does NOT move
back one record.
The only KReportDataSource-derivated class i could find in KEXI is
KexiDBReportDataSource and its movePrevious is implemented as such:
bool KexiDBReportDataSource::movePrevious()
{
if ( d->cursor ) return d->cursor->movePrev();
return false;
}
I have verified that d->cursor, a pointer to KDbCursor, is not null and that
its movePrev() return true.
KDbCursor::movePrev only works if the cursor is buffered, and
KexiDBReportDataSource makes sure of it. The rellevant part of movePrev is:
if (m_afterLast && (m_records_in_buf > 0)) {
drv_bufferMovePointerTo(m_records_in_buf - 1);
m_at = m_records_in_buf;
d->atBuffer = true; //now current record is stored in the buffer
d->validRecord = true;
m_afterLast = false;
return true;
}
It seems that buffering should be implemented by drivers and
drv_bufferMovePointerTo tells the driver’s cursor to move its pointer to the
last record in its cache.
However, i’ve seen that the driver for PostgreSQL does not implement buffering
and SqlCursor does the following:
void SqliteCursor::drv_bufferMovePointerTo(qint64 at)
{
d->curr_coldata = d->records.at(at);
}
It seems that d->records is the “raw” record data from the database —the cache
buffer—, and buffered cursor call drv_appendCurrentRecordToBuffer() to record
the current record to that buffer. However, SqlCursor’s method, even though
i’ve checked it is called, never stores anything inside records because the
first thing it does is:
void SqliteCursor::drv_appendCurrentRecordToBuffer()
{
if (!d->curr_coldata)
return;
…
The *only* time i could find that curr_coldata is set is precisely within
drv_bufferMovePointerTo, that can only set it to null because records has never
been filled.
Moveover, even if somehow curr_coldata were set, i do not see where it is being
used and SqliteCursor::value always calls SQLite3’s function to retrieve the
data from the prepared query. Once sqlite3_step returns SQLITE_DONE after the
last row, the prepared statement can not be used, SqliteCursor:
