dbmsType was previously kept as a private variable in QSqlDriverPrivate,
however it's particularly useful for QODBC users.
[ChangeLog][QtSql][QSqlDriver] Add support for determining DBMS type from SQL driver.
Change-Id: If1c221520da9ac4ccef85a02db078679d76eac92
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Initialize directory delayed in shared code and add checks to verify
that it is valid. Close attached / cloned databases to prevent locks
on files and leaking temporary directories caused by SQLite:
QTemporaryDir: Unable to remove "...\Temp\tst_qsqldatabase-P1XkOA" most likely due to the presence of read-only files.
QTemporaryDir: Unable to remove "...\Temp\tst_qsqltablemodel-P1XkOA" most likely due to the presence of read-only files.
QWARN : tst_QSql::concurrentAccess() QTemporaryDir: Unable to remove "...\Temp\tst_qsql-l0VAKJ" most likely due to the presence of read-only files.
Change-Id: If85bbaed04bb1a32e427d642be332996d967f796
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Joerg Bornemann <joerg.bornemann@digia.com>
Each model test gets its own temporary directory, thus there is no problem parallelizing them.
This should reduce the time spent for a testrun of qtbase by around 3 minutes.
When running only the sql tests it saves less since there are no other tests to run in parallel.
=== Timing: =================== TEST RUN COMPLETED! ============================
Total: 4 minutes 43 seconds
Serial tests: 4 minutes 42 seconds
Parallel tests: 1 second
Estimated time spent on insignificant tests: (no time)
Estimated time saved by -j4: 1 second
=== Totals: 12 tests, 12 passes ================================================
After:
=== Timing: =================== TEST RUN COMPLETED! ============================
Total: 4 minutes 7 seconds
Serial tests: 50 seconds
Parallel tests: 3 minutes 17 seconds
Estimated time spent on insignificant tests: (no time)
Estimated time saved by -j4: 1 minute 23 seconds
=== Totals: 12 tests, 12 passes ================================================
Change-Id: I355ceed62fae852ad8cd442848e263438afb738e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Commit 773dd01 introduced a general mingw platform scope, which
is cleaner and more flexible than matching the spec name.
Change-Id: Ie3a9cb791a83f7c8a51bc4e23069190c452ab521
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
the diff -w for this commit is empty.
Started-by: Thiago Macieira <thiago.macieira@intel.com>
Change-Id: I77bb84e71c63ce75e0709e5b94bee18e3ce6ab9e
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
This removes some XFAILS that were no longer correct and
fixes some existing problems in the tests where ODBC is
concerned.
Change-Id: I91de526bb50ad4046ba07ddb5336aa3714966687
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Reviewed-by: Caroline Chao <caroline.chao@digia.com>
Oracle has a limitation of 30 characters for a tablename so the main
change is to account for this, which meant changing all the usages of
qTableName(). Some other fixes are included that ensure the tests are
working correctly as far as Oracle is concerned.
Change-Id: I8ad8a5a33e6a70fcad235f6a7e82e91687b74fee
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
By moving it to QSqlDriverPrivate we make it easier to check what
database is actually connected which is particularly useful for the
autotests.
Change-Id: I54d1c2c998919c1d54efb1b6ac9303070ece54aa
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
revert() should operate in OnFieldChange edit strategy just as
submit() does. The reason in Qt 4 for excluding OnFieldChange
was that there was no opportunity to revert. The model was
refreshed, causing all changes to be lost. In Qt 5 a failed
edit remains in the cache until user action, which could be
to revert.
Change-Id: Ide021c4f83a53834b7ed81f2abfa3aa49317704d
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Previously, selectRow() did not work after INSERTing a new row into a
table with an automatically populated column. It did not work because
the model did not know the primary values for the new row. Newly
inserted rows were therefore not refreshed in OnFieldChange and
OnRowChange edit strategies.
This change provides support for the typical simple case where a single
column is populated by the database and can be retrieved with
QSqlQuery::lastInsertId().
Task-Number: QTBUG-29102
Change-Id: Ibf0f0ac8661185bde57034ddf40c2178bece4778
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Lukas Geyer <lgeyer@gmx.at>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Commit 10ff9de91b introduced the
optimization of ignoring non-changes, but it overshot the mark.
It neglected to consider that QVariant's equality operator does not
compare the null flag. It also failed to consider that setData() has
a useful side effect of setting the generated flag in a column of a
pending INSERT. This is important when the application actually wants
a NULL to be inserted into the column.
Task-number: QTBUG-29217
Change-Id: I1368f7acc21eebfeb5a8d23746fc38f6f30fd395
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
QSqlQueryModel::headerData() relied on virtual indexInQuery() to
detect whether the requested column at row 0 mapped to an index in
the query. This failed when row 0 was a pending insert managed by
QSqlTableModel, and therefore not in the query.
The only thing that matters here is the column.
Task-number: QTBUG-29108
Change-Id: I3e0ae85ba223e444781ec8033386d394bb44f0e8
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
These types are either built-in or 'automatically declared' and so
don't need to be explicitly declared as metatypes.
Change-Id: Ifd116dee32a450ff89a9a1011e26b434765d6e95
Reviewed-by: David Faure <david.faure@kdab.com>
As they are built-in, they are effectively registered at compile-time
already.
Change-Id: I7ae6ba16088eab5d19213fa7b07c2a7760988a86
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
this is much more elegant than the so far propagated !isEmpty(QT.foo.name).
also replace feature-specific tests (no-gui and no-widgets) and the
obsolete contains(QT_CONFIG, foo) syntax.
Change-Id: Ia4b3c8febcabf9eeca67b1f9173a523820b1038b
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Reviewed-by: Tasuku Suzuki <stasuku@gmail.com>
Reviewed-by: Oswald Buddenhagen <oswald.buddenhagen@digia.com>
geometryengine.cpp: In member function 'void
GeometryEngine::drawCubeGeometry(QGLShaderProgram*)':
geometryengine.cpp:159:93: warning: cast to pointer from integer of
different sie [-Wint-to-pointer-cast] geometryengine.cpp:167:95:
warning: cast to pointer f rom integer ofdifferent size
[-Wint-to-pointer-cast]
benchmarking.cpp: In member function 'void TestBenchmark::multiple()':
benchmarking.cpp:85:9: warning: variable 'result' set but not used
[-Wunused-but-set-variable]
benchmarking.cpp: In member function 'void TestBenchmark::series()':
benchmarking.cpp:120:9: warning: variable 'result' set but not used
[-Wunused-but-set-variable]
qstandarditemmodel.cpp:2717:45: warning: unused variable 'd'
[-Wunused-variable]
qxcbconnection.cpp: In member function 'xcb_timestamp_t
QXcbConnection::getTimestamp()': qxcbconnection.cpp:930:40: warning:
suggest parentheses around assignment used as truth value
[-Wparentheses]
tst_qguiapplication.cpp: In constructor
'BlockableWindow::BlockableWindow()': tst_qguiapplication.cpp:340:9:
warning:'BlockableWindow::enters' will be initialized after [-Wreorder]
tst_qguia pplication.cpp:339:9: warning 'int BlockableWindow::leaves'
[-Wreorder] tst_qguiapplication.cpp:342:12: waring: when initialized
here [-Wreorder]
tst_qsqltablemodel.cpp:570:10: warning: unused parameter 'value'
[-Wunused-parameter]
tst_qabstractitemview.cpp:1546:8: warning: unused parameter 'index'
[-Wunused-parameter]
Change-Id: I49c88547182e4669cfde2c2536403fc5573ca2da
Reviewed-by: Jędrzej Nowacki <jedrzej.nowacki@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Thiago Macieira <thiago.macieira@intel.com>
Test added.
Change-Id: Ibd72ef2aeee482abbd22991573460e55dc577457
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: David Faure (fixes for KDE) <faure@kde.org>
Commit fbf010a266 introduced a version
of record(row) that includes the generated flags, but it neglected to
populate the values using virtual data() as QSqlQueryModel correctly
does.
Test included lest we forget again.
Change-Id: I49d0f8f87cd0c5078aa6a0e8373b2cffc01f2387
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
setRecord() should use setData() as intended so that reimplementations
of setData() in subclasses will be respected.
Commit 11bd543d90 failed to consider this.
Test added which should prevent this mistake being repeated.
Change-Id: Ia2d930cd42b5a27521bb389edb1b07fb1bf0fa36
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: Konstantin Ritt <ritt.ks@gmail.com>
Reviewed-by: David Faure <david.faure@kdab.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
This is good for performance in terms of avoiding unnecessary
database activity and keeping the cache smaller.
Detail:
This change was not included in the big refactoring of QSqlTM. The
idea was that the model shouldn't second guess the intention of the
application and maybe the application wants to cause a submit.
It was a marginal consideration.
Now I think it's clear that our interest in not unnecessarily
expanding the cache outweighs that. In addition, applications can now
call selectRow() if they worry that the database values for the row
have changed and want to set a value back again.
Test added.
Change-Id: I63814dcb63a96c6ba1c8cc227807725a954a0b68
Reviewed-by: Marc Mutz <marc.mutz@kdab.com>
Reviewed-by: David Faure <david.faure@kdab.com>
The STL-style iteration over the cache in submitAll() assumed the
iterator would remain valid until reaching cache.end(). This failed
to consider that virtual selectRow() might be overridden so that
it removes rows from the cache. For example, it might call select()
which would empty the cache.
The new approach checks at each iteration whether the row is
still in the cache. Using foreach here is justified by its fitness
for purpose and readability.
New test included.
Change-Id: Idee8807ede239c3ba56ff1604574c49f47385ad2
Reviewed-by: David Faure (fixes for KDE) <faure@kde.org>
This method was originally intended for refreshing rows after
submitting changes. It should also work for refreshing rows
that are unchanged (i.e., not cached), but did not because
constructing the primary values depended on the cache. As a
consequence, the WHERE clause for the query was not created.
Fixed by deriving primary values for uncached rows from the
query record. Note that the cache is still authoritative for rows
it holds. This is important because the prmary values there may
differ from the original query record due to changes to columns
of the primary key.
Includes new test.
Change-Id: I41cca2cbf26019d4b495ffa6d876e2b55ec57803
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Change copyrights and license headers from Nokia to Digia
Change-Id: If1cc974286d29fd01ec6c19dd4719a67f4c3f00e
Reviewed-by: Lars Knoll <lars.knoll@digia.com>
Reviewed-by: Sergio Ahumada <sergio.ahumada@digia.com>
Follow-up to 83c9ebbd66.
Consider the case where calls to the reset methods on the same object
are nested as in the following sequence:
1. beginResetModel()
2. beginResetModel()
3. endResetModel()
4. endResetModel()
In such cases, only the outermost calls, i.e., 1) and 4), should emit
signals.
After 83c9ebbd66, 1) and 3) emitted the
signals, which is wrong. This is corrected by keeping track of the
nesting level.
Such sequences can come about when a base class calls the begin/end
methods between the calls made by the subclass.
QSqlTableModel::select() is an example of this.
Test included.
Change-Id: Ia62b45cb1abaab00a32bb8357de4a958bcff83e5
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Qt 5.0 beta requires changing the default to the 5.0 API, disabling
the deprecated code. However, tests should test (and often do) the
compatibility API too, so turn it back on.
Task-number: QTBUG-25053
Change-Id: I8129c3ef3cb58541c95a32d083850d9e7f768927
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Previously the method attempted to reset only as a last resort.
Now reset() is deprecated and resetting must happen between emitting
modelAboutToBeReset() and modelReset(). Since this suffices in all
cases to notify views that they must reinterrogate the model, it is no
longer necessary to signal explicitly row removals and insertions
within the scope of the reset.
Additionally, fetchMore() is now called within the scope of the reset
so insert signals do not have to be emitted here either.
This improved handling of resetting in QSqlQueryModel also allows the
cache in QSqlTableModel to be cleared directly at select().
This change may actually allow views to operate more efficiently since
they no longer have to react to separate row removal and insert
signals. Views can avoid pointless deallocation and reallocation
by considering row count only after the reset is finished. The cost is
that the columns and horizontal headers must be considered in the view
at each setQuery() call. In any case, it is not clear that trying to
be smart about this in the model justifies additional complexity.
Tests had to be adjusted where they expected explicit row removal
and insert signals.
Change-Id: I4f7eac1419824361d7d9bdcc6a87092b33e80d7a
Task-Id: QTBUG-25419
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Olivier Goffart <ogoffart@woboq.com>
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
QSqlTableModel::headerData() generates a crash if an invalid filter
is set. QSqlQueryModel::indexInQuery() should check the index value
before applied to d->colOffsets[].
QSqlQueryModel::initRecordAndPrimaryIndex() is updated to sync the
size of rec and colOffsets.
Task-number: QTBUG-23879
Change-Id: Ic9f88bb288592aa6fb3c1415cc818632dadaab56
Reviewed-by: Michael Goddard <michael.goddard@nokia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
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>
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>
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>
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>
Fix up for f5e1da12f0.
Change-Id: I3a730ce7e47d71551a46cc105ba2d1fe4e33b65b
Reviewed-by: Robin Burchell <robin+qt@viroteck.net>
Reviewed-by: Yunqiao Yin <charles.yin@nokia.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>
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>
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>
