Introduce value overload to take field name as a parameter.
This allows for terser application code that avoids explicit
calls to QSqlRecord::value().
Change-Id: I02b6712cd5ec41633b902714315b5716c17d1a9b
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
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>
This is an automated change performing the following replacements:
join\("(.)"\) -> join('\1')
join\(QLatin1String\("(.)"\)\) -> join(QLatin1Char('\1'))
join\(QStringLiteral\("(.)"\)\) -> join(QLatin1Char('\1'))
Change-Id: Ie395d82d17710683968d006d22de313ef49dc6e5
Reviewed-by: Harald Fernengel <harald.fernengel@nokia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
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>
SQL Server 10 introduced stricter rules for TIMESTAMP validation,
making it necessary to specify the decimal digits.
Other databases might do the same as well, so this patch introduces
a check for the TIMESTAMP column size and adjusts the decimal digits
parameter as needed.
Task-number: QTBUG-2192
Change-Id: If6d798c6c928ebda75bc474e49a07fbbfbe5816c
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
These tests have passed a parallel stress test on all three of Linux,
Mac, Windows. Mark them with CONFIG+=parallel_test to allow CI to run
them in parallel, saving time.
Change-Id: I19fd333c3c645a67374ca998f6c8530dd236b0f8
Reviewed-by: Toby Tomkins <toby.tomkins@nokia.com>
The file has been UTF-8 encoded for years, which means that the line:
QString longerBLOB( "abcdefghijklmnopqrstuvxyz¿äëïöü¡ " );
Loaded a mojibake into QString. Then, this data was stored as a blob
in the database by calling longerBLOB.toLatin1() (a QByteArray), and
reloaded for check using toString().
Once the QString default codec changes to UTF-8, the mojibake would
get fixed, and the test would fail. Make sure it doesn't happen.
Change-Id: If12d6124c973e4a1c1b7978d90fffb9aa5545c66
Reviewed-by: Lars Knoll <lars.knoll@nokia.com>
This operation should be a no-op anyway, since at this point in time,
the fromAscii and toAscii functions simply call their fromLatin1 and
toLatin1 counterparts.
Task-number: QTBUG-21872
Change-Id: Icb3ab0e1f4f3173563f3de36115b5457cf1ba856
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
qVariantValue and qVariantCanConvert are Compatibility members, while in
Qt4.8 they are marked as Qt 3 Support Members.
qVariantFromValue and qVariantSetValue are Obsolete members.
Change-Id: Ie8505cad1e0950e40c6f6710fde9f6fb2ac670fd
Reviewed-by: Friedemann Kleint <Friedemann.Kleint@nokia.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>
Follow-up to c55a99965d8c08d5f924d49db4fe4aa49df8096.
3 problems prevented stored procedure output parameters from working.
- SQLBindParameter needs access to buffer provided by QByteArray.
- The length of the buffer is measured in bytes.
- A typo corrupted conversion back to QString.
Also, data() makes more sense than constData() to expose the buffer.
Task-Id: QTBUG-18435
Change-Id: I66444b13c0f584ed79bcf026e5a23caff83c22cb
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
The placeholder name must include the : prefix.
Several type tests for aggregate functions assumed sqlite behavior
which is actually exceptional due to sqlite's loose type system.
REAL is a synonymn for DOUBLE in sqlite but is also compatible with
at least MS SQL Server, PostgreSQL, Oracle, and MySQL.
Change-Id: I97f8c55d2e962b072cfab11a121fda685666e754
Reviewed-by: Harald Fernengel <harald.fernengel@nokia.com>
Applied Bill King's suggestion in QTBUG-1363. Columns of
hStmt must be accessed in order.
Verified using ODBC driver on SQL Server 2005 on Windows 7.
Added test for length of text field for MS SQL Server over ODBC.
Task-Id: QTBUG-1363
Change-Id: I6673dafe75e3ef394d41e439adb45096c1421068
Reviewed-by: Bill King <bill.king@nokia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
According to documentation, SQLite doesn't have a separate Boolean
storage class. Instead, values are stored as integers 0(false) and
1(true). In QSqlQuery::bindValue(), if a boolean value is bound
to a placeholder, it is converted to text true and false. This fix
converts boolean value to integer 0 and 1.
Task-number: QTBUG-23895
Change-Id: I4945971172f0b5e5819446700390033a1a4ce301
Reviewed-by: Michael Goddard <michael.goddard@nokia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Postgres async notifications can contain a payload parameter
that is currently discarded. This patch provides the QSqlDriver
api change necessary to deliver a payload with each emitted
notification by adding a QVariant parameter to the notification
signal. It also provides the implementation for the qsqlpsql driver.
The qsql_ibase driver has been updated to reflect the change to the
notification signal signature.
The eventNotificationPSQL test in the qsqldatabase test has
been expanded to test proper payload sending and receiving.
All tests/auto/sql/kernel tests have been run with sqllite and
postgres with no regressions.
Task-number: QTBUG-13500
Change-Id: I9137f6acc8cfca93f45791ca930e0287d93d5d0d
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
Tests added that cover boundValues with positional binding,
and boundValueName.
Change-Id: I2962d76607b716d19d3e0be958109be2f032f2d9
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
This patch fixes a critical bug in the qsqlpsql driver where
notifications aren't delivered when received. Any blocking libpq
function(specifically PQexec) will read all the incoming data
from the socket, including any pending notifications. This would
cause the socket notifier to never be fired for incoming
notifications that are already queued inside libpq. The qsqldriver
test case was skipping the postgres notification test because of
this bug, now its enabled and passing. In order to fix this
bug I made a wrapper function for PQexec in QPSQLDriverPrivate
that calls _q_handleNotification via QMetaObject::callMethod
QueuedConnection in order to deliver pending notifications
when control returns to the event loop. I also added a flag
to ensure only one call is made each time the event loop is
entered.
Change-Id: I19f5297094ae7ae46bfb0717e4fca744d69f7b92
Reviewed-by: Honglei Zhang <honglei.zhang@nokia.com>
Reviewed-by: Mark Brand <mabrand@mabrand.nl>
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>
Prepared queries should be able to use a name parameter more than
once. Currently this will result in undefined behavior and crashes.
This patch fixes the bug and implements the needed test case.
Task-number: QTBUG-6420
Change-Id: I07d6537e432a9b2781e9ef3d9f597bceb054527e
Reviewed-by: Andy Shaw <andy.shaw@digia.com>
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>
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>
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>
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>
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>
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>
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>
