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>
Use submit() instead of calling updatRowInTable(). The effect is
exactly the same. Submit() invokes submitAll() which invokes
updateRowInTable(). The cache is purged and select() is called only
on success.
Change-Id: I3de9a3d6acf802ee6594d034a9e261e53637995d
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Emit dataChanged() before a possible new select instead of after.
The select reinserts all the rows, emitting signals for that, so
there isn't any point to dataChanged() afterwards.
Change-Id: I698a0d385f97104891343d94cc27e4ecf3a7233c
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Affects setData() and setRecord().
Previously dataChanged() was suppressed when editing an inserted
record, except for OnManualSubmit. The motivation was probably to
allow setData() to be used while handling primeInsert().
Suppressing dataChanged() is not a good idea since views other than
the one which made the change will not know of the change.
It is a terrible idea to call setData() or setRecord() while
handling primeInsert(), so this is now expressly forbidden.
setData() and setRecord() now do nothing and return false if called
while rows are being inserted.
Change-Id: I96738c09a6268704c5626d95b72bfb46378e3242
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
submitAll() is supposed to be for OnManualSubmit.
Change-Id: Id0335fe731669bd24e1da72ab4724f88d6f1d905
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
If an invalid range of rows is specified, it's likely to be a
programming or user error. The old behavior of ignoring out of range
rows seems dangerous and complicates the code.
Also implement the documented behavior of returning false if
changes are unsuccessful for OnFieldChange and OnRowChange.
Previously the return value of submit() was ignored.
Updated and improved documentation.
Change-Id: Iaaf51c6d9a0c8c06fd5d186b4b88358fbeab9936
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Qt 5 seems like a welcome opportunity to stop emitting this
spurious beforeDelete signal.
Change-Id: Ib8628343ca9b8fdd85c154a206c7e2bf2c4c9dc1
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Even though ModifiedRow is not part of the public API, guarding its
data helps make clear the intended patterns of use.
"op" and "primaryValues" are read-only after construction.
setValue() encourages maintainers to let ModifiedRow manage the
"generated" flags of the record.
The primeInsert() signal still exposes the actual record, including
the "generated" flags, which is the justification for recRef().
Change-Id: I16d1610a8f9233af78b90662b08706b48ea19c41
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
-move logic out of switch statement
-clear cache more clearly for OnFieldChange
-call setValue() in one place instead of two
-eliminate extra return path
Existing idiosyncracies have been kept for the time
being.
Change-Id: Ia4c5a5fd3e374b53e3c4d870f2ee9d37b5090917
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
-Do not use setData()
We're using ModifiedRow now so it makes sense to buffer the changes
and submit the row at once. This improves readability and
encourages further haromonization of the editing strategies.
-No longer need temporary change to OnRowChange
Previously, the strategy was temporarily changed from OnFieldChange
to OnRowChange in order to obtain the desired behavior from setData().
Now, since we don't use setData(), we can program the desired behavior
here and don't need this trick.
-Comment historical idiosyncracies/bugs
Change-Id: I6d9e2a69e1571a74c630ad1392e15b60fc0ad3f2
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
Previously ModifiedRow was used only for OnManualSubmit and
a seperate buffer and utility methods were used for OnFieldChange
and OnRowChange.
Also, initialization of the edit buffer is done by ModifiedRow
instead of a helper function.
Change-Id: I3316498e5bb10c416138ca14c3a7f8b143c8e544
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
The 'real' datatype should be seen as a QVariant::Double type and not as
a QVariant::String type otherwise it does not get presented correctly
when using a non Qt application to access it.
Test is included for QSqlQuery.
Task-number: QTBUG-16373
Change-Id: Ie323ce49eb95e4d6bb4c3814ba9a957a63f4b259
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
(cherry picked from commit b23631015c23a49e3b4d296ea0a6266bfce3d4f1)
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Implements the new notification signal in all QSql drivers which use notifcation.
In qt5 only ibase and psql have a notification implementation.
PSQL differentiates correctly between 'SelfSource' and 'OtherSource' whereas
ibase only signals 'UnknownSource' as a default implementation.
Change-Id: Ifcaa139b7a980ed852cf817b3f93284609360ca7
Reviewed-by: Torben Dannhauer <torben@dannhauer.info>
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
To differentiate between signals of different sources types, this submission adds an enum and extra signal to provide it.
Change-Id: Iad711739c41894e9c74d83072c50ae17edc695f2
Reviewed-by: Torben Dannhauer <torben@dannhauer.info>
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
After discussion with Liang, I'm reverting it as he requested. This change put every header into the SYNCQT.HEADER_FILES twice for in-source builds, and the qtMODULEversion.h header did not include a path component.
This reverts commit 2fbc45b58bba860abf67fb28aa1319c9f4ededaf
Change-Id: Ie84cef19193ce5e49072f1f67a41140d9d2673b8
Reviewed-by: Liang Qi <liang.qi@nokia.com>
As in the past, to avoid rewriting various autotests that contain
line-number information, an extra blank line has been inserted at the
end of the license text to ensure that this commit does not change the
total number of lines in the license header.
Change-Id: I311e001373776812699d6efc045b5f742890c689
Reviewed-by: Rohan McGovern <rohan.mcgovern@nokia.com>
It was put in source tree before.
Task-number: QTBUG-20439
Change-Id: Ib52d9c2e83ae375aad259ddc74138bbc728b3ed0
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@nokia.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
These defines were there to aid in the commercial
licensing scheme we used long ago, and are no longer needed.
Keep a QT_MODULE(x) define so other modules continue compiling.
Change-Id: I8fd76cd5270df8f14aee746b6cf32ebf7c23fec7
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
The compile error got introduced due to the
change in QMetaType requiring fully defined
types for pointers.
Change-Id: I6383ff5923fc1d5bd3c1161e2823e83f2a06a99e
Reviewed-by: Stephen Kelly <stephen.kelly@kdab.com>
This is a source incompatible change for Q_DECLARE_METATYPE(T*),
which now requires T to be fully defined.
The consequences of this are:
* Forward declared types can no longer be declared as a metatype.
(though this is a very uncommon thing to do).
There is a trivial workaround where necessary.
Change-Id: Id74c40088b8c0b466fcd7c55abd616f69acc82c8
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Change-Id: I6db7211fcf6b24bd75e360645bbb2fdf1ef8a8bc
Reviewed-by: Frederik Gladhorn <frederik.gladhorn@nokia.com>
Reviewed-by: João Abecasis <joao.abecasis@nokia.com>
Even though it is stated in the documentation that the SQL driver must
remain valid during the life time of QSqlQuery, there are users who don't
follow the rule. It's common that the destructor of QSqlQuery is called
after the driver is already deleted. This fix checks the validity of
the SQLite driver before QSqliteResult uses it in destructor.
Task-number: QTBUG-16967
Change-Id: If0f52113f12e14102da1671cd6e12bdaa267114f
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
QSqlRelationalTableModel doesn't follow relations on the first column
of a table. The DisplayRole and the EditRole for indexes on column 0
are always the same. The bug is found in QSqlRelationalTableModel::data.
Task-number: QTBUG-20038
Change-Id: Ie1e98b5f46ffc171113f2d51b9b19ff5febb1c3c
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
If an ongoing query is not finalized before close function is
called, sqlite driver still tries to close the connection to
sqlite. In this case, sqlite reports an error to sqlite driver
which is not reported to the client. The failure in close causes
connection to sqlite unclosed and memory is not freed. This
fix tries to finalize all queries before close function is called.
The close function should succeed.
Task-number: QTBUG-16967
Change-Id: I2f10a2a9017446a9d44b693b00464a89625e3602
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
SQLite driver support only one statement at a time. This fix makes the
exec and prepare call failed if more than one statements are given.
This is bug fix for QTBUG-21884. Also the behaviour is documented in
the API specification.
Task-number: QTBUG-21884
Change-Id: If1e25a0dd9f9ee38961ef478fc7909f6b05e360a
Reviewed-by: Yunqiao Yin <charles.yin@nokia.com>
When a table that is related to in a QSqlRelationalTableModel gets
updated in some way (e.g. a new row, or the data is changed) then the
related model could not be updated without recreating the
QSqlRelationalTableModel.
Now, to get around this, select() can be called on the related model to
get it to be updated.
Task-number: QTBUG-7885
Reviewed-by: Charles Yin
Reviewed-by: Michael Goddard
Change-Id: Ic589e840234f3a809bcb112a807a87afe0bc25ca
(cherry picked from commit 2c60a4f67f9fb02f3b711fe749b2f293a07b4e02)
Reviewed-on: http://codereview.qt.nokia.com/2224
Reviewed-by: Charles Yin <charles.yin@nokia.com>
Instead of using a simple INNER JOIN, like:
SELECT a,b,rel.c FROM table1, table2 WHERE (table1.smthing =
table2.smthing)
which doesn't show row where foreign keys are NULL, allow use of LEFT
JOIN like:
SELECT a,b,rel.c FROM table1 LEFT JOIN table2 ON table1.smthing =
table2.smthing
The trick works also for multi-relational tables.
Just remember to use the new API setJoinMode.
Signed-off-by: DaNiMoTh <jjdanimoth@gmail.com>
Task-number:QTBUG-8217
Reviewed-by:Michael Goddard
Reviewed-by:Charles Yin
Merge-request: 2576
Reviewed-by: Charles Yin <charles.yin@nokia.com>
(cherry picked from commit c4280dbd9bb37cca21d007f5f8b9217f80b44043)
Change-Id: I349f9418e4859923977942add59872b000cac2c5
Reviewed-on: http://codereview.qt.nokia.com/1853
Reviewed-by: Charles Yin <charles.yin@nokia.com>
This enables external modules to also make use of them without having
access to the complete QtBase source code.
Change-Id: I056e45cba6c6798b76670b8d238dadb2d9f9c092
Task: QTBUG-19585
Reviewed-on: http://codereview.qt.nokia.com/234
Reviewed-by: Marius Storm-Olsen <marius.storm-olsen@nokia.com>
tables() returns tables in all databases on the server"
This bugfix has been rewritten to match contributors advise.
Change-Id: I3a9cf900ff7eae47c9ffdbcf34bcb1b4396d9837
Merge-request: 1010
Reviewed-by: Charles Yin <charles.yin@nokia.com>
(cherry picked from commit c0ca29efdeb442a6b88ccadff409e3f7ef828ce8)
This will allow us to expose private headers in a controlled manner,
and ensure that they are not used by accident. This also means that
we internally will have to enable the private headers for the
modules we wish to use in the project.
This is the beginning of revision history for this module. If you
want to look at revision history older than this, please refer to the
Qt Git wiki for how to use Git history grafting. At the time of
writing, this wiki is located here:
http://qt.gitorious.org/qt/pages/GitIntroductionWithQt
If you have already performed the grafting and you don't see any
history beyond this commit, try running "git log" with the "--follow"
argument.
Branched from the monolithic repo, Qt master branch, at commit
896db169ea224deb96c59ce8af800d019de63f12