General changes:
const, scope, braces, hash[] for clarity, comment wording and
spelling.
QSqlRelationalTableModel::selectStatement() readability:
Renamed private method.
QVector<Class>.value() already defaults to null object value, so there
is no point in handling this case explicitly.
Alias rec for d->rec added more noise than clarity.
Using "tables" list only adds an extra step. Simple concatenation does
the trick.
Deduplicate code for building table expression and JOIN condition.
Change-Id: Ia52afaf3c3937a26595d5ae867982664002562d8
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
For OnFieldChange and OnRowChange, we don't want more than one row in
the cache with uncommitted changes. This could happen if deletion in
the database fails while other changes are pending.
Chosen solution is to return false if other rows have pending changes.
Also, we only allow 1 row removed at a time.
Updated test, changes and documentation.
Change-Id: I68baf6d221789b4754e891535070011c759a2155
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
The model can never do a good job of knowing when user moves to a
new row in the view. Faking it by detecting when another row
is changed was not a good solution because it cannot detect
when the last edited row is left.
Either the view should automatically submit when the user leaves
a row or the application should provide a way to submit.
This change made it possible to reuse the logic of flags() in
setData().
Change-Id: I2550e5b113bceba1a852fc21203babeca07c5748
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
For OnFieldChange and OnRowChange, inserting rows should not be
allowed if there are pending changes in cache.
Change-Id: Ia794332959a35a1de87e798ba1a74ace3dfae68f
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
For OnFieldChange and OnRowChange, before submitting new changes,
setData() and setRecord() attempt to submit pending changes and
revert them upon failure. However, they fail to consider that
reverting pending insertions removes rows from the model. As a
result, the new change can be applied to a row higher than intended.
One possible solution would be to adjust the targetted index for the
removed rows, so that the intended row is affected by the new change.
But this still causes the strange editing experience as rows jump
up just as they are being edited.
It does not seem right in the first place for the model to initiate
reverting changes. It should be up to the application to decide what
to do when data cannot be committed. In particular, setData() and
setRecord() should not have the side effect of reverting already
pending changes.
The chosen solution is simply to refuse new changes that don't make
sense for the edit strategy. For OnFieldChange, flag() will
indicate read-only when editing is blocked by a pending change.
Since setData() and setRecord() submit data immediately for
OnFieldChange, it no longer makes sense to resubmit changes
automatically before a new change.
For OnRowChange, setData() keeps the behavior of automatically
submitting a pending row before starting on a new row. This is
historical behavior and is probably motivated by the fact that
QTableView does not automatically call submit() when editing leaves a
row. The obvious shortcoming of this is that the last row to be edited
will not be submitted automatically. It also prevents us from flagging
rows other than the pending row as read-only.
For OnRowChange, setRecord(), being row-oriented by nature, should
submit the change immediately rather than waiting for the next call
to setRecord(). This makes setRecord() consistent with insertRecord().
Change-Id: Icb4019d8b7c53a7ee48f8121a7a525e8bc35d523
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
According to SQLite documentation, a database connection handle
is usually returned, even if an error occurs. This behavior has
caused Qt to leak memory when opening a database is failed. Now,
even if sqlite3_open_v2() does not return SQLITE_OK, Qt tries to
release SQLite database handle by calling sqlite3_close().
Task-number: QTBUG-15773
Change-Id: I6538e2897216828a9cfb95b7d4a5cec437aa6c28
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Michael Goddard <michael.goddard@nokia.com>
Checks if model has any changes to submit.
Includes new test covering isDirty(index) as well the new
overloaded function.
Task-number: QTBUG-3108
Change-Id: I0ccbda45d5d9f06434cf1e1c037a9efb76d0cc37
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
Commit b979956ec4 introduced a
distinction between rows that have a pending INSERT operation and
rows that have already been inserted in the database but still are
in the change cache. Both cases are rows that are not in the underlying
query. Unfortunately, we overlooked a case where the point of the test
is whether the row is in the query.
Change-Id: I0f58bed232d9336fed6e67c3d140fd580ec35868
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
This is a semi-automatic search, so I'm
reasonably sure that all the exported ones
have been caught.
Change-Id: I3a79f66f9705bc991175f396138efe3088727a85
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
Mention in changes and document Qt version (merci à dfaure).
Follow-up to 291e2c7d54.
Change-Id: Ie5626e9cd268812c1173ca494ccd8d6bd9be2687
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
When an aggregate function is used for a column in a SQL resultset then
it should ensure that the right data type is reported for that column.
This also concerns expressions when the returned column does not map
directly to a table column.
Test included for this.
Task-number: QTBUG-22038
Change-Id: I07487694c0ed393d46af06e232914fe923356a99
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
Calling select refreshes the query data but disrupts view
navigation.
For OnFieldChange and OnRecordChange it makes sense to only
select the row in question. This does not disturb view navigation.
Assume disruption of view navigation is not a problem
for OnManualSubmit because the user or application decides
when submitAll is called.
Task-number: QTBUG-2875
Change-Id: I1e5f68668fb9102f6296d67d543e80daa403f1c4
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Once an insert has been submitted, the cached record behaves like an
update. For row bookkeeping, we still have to remember that it was
originally inserted and is not in the query rows.
Between submitting a delete and selecting, we remove the values
from the deleted record. This causes a blank row to be displayed.
Read-only flag is set for cells in deleted row.
Reverting between submit and select means going back to the last
submitted values.
When removing rows, it's better to process from highest row numbers
to lowest. This avoids complications with higher rows shifting down
when lower rows are removed.
Change-Id: I8752fa11f7a1b88f2a71b9e03a020ac37e62487f
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
Simplify logic. If the record is in the cache, even untouched
values should be there. This is also necessary for getting
the most up-to-date values between submitting and the next
select.
Change-Id: I8578d96229797ce9fb0d07fe456301358f2be071
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
Primary values are used to map a row in the model to a row in the
database table. It is critically important between submitting a
change and the following select (which refreshes the query) to have
updated primary values. Otherwise, if the change affected the primary
values, additional changes before select will misbehave.
Change-Id: I5d08dd70ac5d3f06cd9d3186a439f4c80a037c2d
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Between submitting and the next select, these values will be more
up-to-date than those that could be obtained from the query.
This will be useful for constructing primary values and reverting
changes made after submitting.
Change-Id: I8317617f3e7043ad0b79b333731c55fb88aef171
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
QDoc now has support for Doxygen style commands for italics, bold
and list items. This change applies that change in QDoc to the
actual documentation.
Task-number: QTBUG-24578
Change-Id: I519bf9c29b14092e3ab6067612f42bf749eeedf5
Reviewed-by: Shane Kearns <shane.kearns@accenture.com>
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
The code in submitAll() had the same goal as the code in select,
so it has been unified. The new code in select() avoids sending lots
of dataChanged() signals for rows that are going to be removed
by QSqlQueryModel anyway.
Change-Id: Ic22e038223720185e47ed0cc573147745ecc8fc9
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Q_WS_WIN does not exist any more.
Change-Id: Icb7f542cfcd4d21e994f246ff665583cb6b57610
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.com>
The consensus on #qt-labs seems to be that there is little or no
point in checking with contains() before using value(), even if
the map does not contain the key in most cases.
Change-Id: I34740a91d5c3af65e20937a5ae3b4bab32406440
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
No supported compiler defines it, and it was not used consistently
so it didn't work anyway.
Change-Id: Icc9e911e22daaedaee3d9316c15d19be26cd2e72
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
QSqlDatabase::database() is documented to be thread-safe and when the
driver is queried for the numericalPrecisionPolicy set then it can
comprimise the thread-safety.
Since the driver itself (if one is set) will be queried for the
numericalPrecisionPolicy when numericalPrecisionPolicy() is called on
the QSqlDatabase then we can have it fallback to the default instead
rather than taking the driver's own setting.
Task-number: QTBUG-13423
(cherry picked from commit e7e9fca6c0cd1d0869029fc6e9d7605234ee5bb2)
Change-Id: Ie7e9fca6c0cd1d0869029fc6e9d7605234ee5bb2
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Should return invalid QModelIndex since inserted row does not map to
query.
Change-Id: Ib1d15cf4198a7063717fb3f3b594b2b1d8a54dfe
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
It's not appropriate to use indexInQuery() here. First of all,
the row might be an inserted row, and thus not be in the query.
The intent was probably to get the column position in the query,
but this is certainly not row dependent. Furthermore, if there
are inserted or removed columns, these are managed within
QSqlQueryModel.
Change-Id: I89668655b263747a5b849136404112e911722b3d
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Consider what happens the 1st change succeeds and the 2nd fails. No
select will be done. When submitAll() is called again, the 1st will
still seem to be pending. It will fail or have unexpected effects if
the primary values were changed.
The solution is to avoid resubmitting successful changes. We leave
them in the cache so they stay visible. Submitted changes cannot
be reverted of course.
Change-Id: Ibf400555effa1c3801d02f8713b4b69856ede23a
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
They can be generated on demand regardless of edit strategy.
Change-Id: I1e1853e93cc453f1486b65ce577f00141b9c5c47
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
There is no reason for the caller to be concerned with this.
primaryValues() now takes advantage of the fact that QSqlQueryModel
uses indexInQuery which was recently made virtual.
Change-Id: I7d856ee05f55c3199fd17c618e559320d0582989
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
The purpose of the hack was to fool QSqlQueryModel into signaling the
removal of extra rows via rowsRemoved(). The extra rows are the
inserted rows generated by QSqlTableModel.
While it is important to signal the removal of all the rows before
requerying after committing changes, there is a cleaner way. The
table model should remove its rows before the query model removes its
rows.
Iterating backwards avoids having to decrement row numbers above ones
being removed.
Expected test results have been adjusted for these changes.
Change-Id: I0e8aa81f5e7b8fea5922f5ffd1cfb4a932313a10
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Reading STL iteration code is painful enough if you only have
to do it once.
Thiago suggested remembering the end iterator for performance.
Change-Id: Ic2cdc480f591932ea420e692a4d2796d49f05313
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Qt 5 seems like an excellent opportunity to simplify logic and separate
concerns by making indexInQuery() virtual. Note that this wasn't my
idea, but was mentioned in a helpful comment.
Change-Id: Ie29ead110def45297c32de3ce6d07a8eefb08d8c
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
-Only use fields where generated flag is set to true.
-Require all fields to map correctly. If fields don't map, that is a
sign of a programming or user error.
Change-Id: Ie8474393005de6c9926b4e46985d62b194eafde2
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
To hide the IsPointerToTypeDerivedFromQObject monstruosity :-)
Documentation for Q_DECLARE_METATYPE and qRegisterMetaType was updated
to mention requirements on registered types and how they can be
circumvented for pointer types with the new macro.
Change-Id: If83b037a8e2f28761eb903525e87008107298801
Reviewed-by: Harald Fernengel <harald.fernengel@nokia.com>
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
Previously, if any fields in the supplied record could not be matched
with a column in the target table, dataChanged() was supressed for all
columns for OnManualSubmit. This is not good because it prevents other
views from noticing the fields that *do* change.
It's simplest and probably more efficient just to emit
dataChanged() once for the whole row. Fewer signals need to be
processed and in typical cases much or all of the row is likely to
be changed anyway.
Change-Id: Ib56bf9a18e51b9cb85771acefcb2bf26e295a54e
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
In an apparent attempt to be economical with emitting dataChanged()
and submitting SQL to the databse, setRecord() compares each field
value of the record with the old value, taking action only when
a difference is detected. Several complaints against this code are:
-The comparision does not work on float type.
-It is really up to the application and database to decide this. The
model should make few assumptions. The application has the option to
omit fields from the record that should be ignored.
-The current behavior seems to assume that the "old" values are the
current state of the database, but the database may have changed since
the model was last refreshed.
-The code compares the value from record(), which probably
corresponds to the EditRole, with the DisplayRole value from data().
Change-Id: I11477c185eb411d442144dc682893d0df12d03d5
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Kent Hansen
Mark Brand
Honglei Zhang
Lars Knoll
Marc Mutz
Andy Shaw
Casper van Donderen
Debao Zhang
Stephen Kelly
João Abecasis