joomla-framework / database Goto Github PK
View Code? Open in Web Editor NEWJoomla Framework Database Package
License: GNU General Public License v2.0
Joomla Framework Database Package
License: GNU General Public License v2.0
Check if the 2.0-dev branch contains the changes from following PRs: #217 , #219 , #220 .
It does.
It doesn't.
Not relevant here.
It seems to be a while ago when the 2.0-dev branch was updated with changes from the master branch.
Review Travis HHVM tests, mysqli_stmt::get_result()
is not available on HHVM
no error
Fatal error: Call to undefined method mysqli_stmt::get_result() in /src/Mysqli/MysqliDriver.php on line 635
HHVM 3.15.3
HHVM won't fix this but would take a PR to add the functionality
facebook/hhvm#2368
As such we have 3 options
AppVeyor's free option only allows for 1 concurrent job, this can create long wait times for builds as they are stuck in the Queue.
I suggest that we choose to only test php 5.6 or php 7.1 on AppVeyor to reduce the overall wait on builds (I would preference php 7.1)
Another option is to convince the PLT to pay for AppVeyor's service to get faster builds with more concurrent jobs.
The last option is to just accept the slow build window and the long Queue waits.
Please remove junk from the merge conflict.
database/src/Pdo/PdoDriver.php
Lines 595 to 636 in ac02265
The Mysqli Iterator fails the unit tests. Off hand from the failures, it seems there may be an indexing issue adding an additional row to the arrays.
There were 4 failures:
1) Joomla\Database\Tests\IteratorMysqliTest::testForEach with data set #0 ('title', '#__dbtest', null, 'stdClass', 0, 0, array(stdClass Object (...), stdClass Object (...), stdClass Object (...), stdClass Object (...)), null)
136
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
0 => stdClass Object (...)
1 => stdClass Object (...)
2 => stdClass Object (...)
3 => stdClass Object (...)
+ 4 => stdClass Object (...)
)
/database/Tests/IteratorMysqliTest.php:137
2) Joomla\Database\Tests\IteratorMysqliTest::testForEach with data set #2 ('title', '#__dbtest', null, 'stdClass', 20, 2, array(stdClass Object (...), stdClass Object (...)), null)
136
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
0 => stdClass Object (...)
1 => stdClass Object (...)
+ 2 => stdClass Object (...)
)
/database/Tests/IteratorMysqliTest.php:137
3) Joomla\Database\Tests\IteratorMysqliTest::testForEach with data set #3 ('title, id', '#__dbtest', 'title', 'stdClass', 0, 0, array(stdClass Object (...), stdClass Object (...), stdClass Object (...), stdClass Object (...)), null)
136
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
'Testing' => stdClass Object (...)
'Testing2' => stdClass Object (...)
'Testing3' => stdClass Object (...)
'Testing4' => stdClass Object (...)
+ 'testRollback' => stdClass Object (...)
)
/database/Tests/IteratorMysqliTest.php:137
4) Joomla\Database\Tests\IteratorMysqliTest::testCount
153
Failed asserting that 5 matches expected 4.
/database/Tests/IteratorMysqliTest.php:154
Review AppVeyor tests in PR #72
no Postgresql / PDO Postgresql driver issues on windows
the following failures occurred with GetCollation()
and GetVersion()
There were 4 failures:
1) Joomla\Database\Tests\DriverPgsqlTest::testGetCollation
224
Failed asserting that 'English_United States.1252' contains "UTF-8".
C:\projects\database\Tests\DriverPgsqlTest.php:224
2) Joomla\Database\Tests\DriverPgsqlTest::testGetVersion
465
Failed asserting that '9.4.7' is equal to <string:9.4.7,> or is greater than '9.4.7,'.
C:\projects\database\Tests\DriverPgsqlTest.php:465
3) Joomla\Database\Tests\DriverPostgresqlTest::testGetCollation
224
Failed asserting that 'English_United States.1252' contains "UTF-8".
C:\projects\database\Tests\DriverPostgresqlTest.php:224
4) Joomla\Database\Tests\DriverPostgresqlTest::testGetVersion
465
Failed asserting that '9.4.7' is equal to <string:9.4.7,> or is greater than '9.4.7,'.
C:\projects\database\Tests\DriverPostgresqlTest.php:465
n/a
The full control panel with modules is shown.
The control panel has no modules.
PHP 7.2.8
MySQL 5.7.22
Client API library version | mysqlnd 5.0.12-dev - 20150407
Joomla 4
The query executed is
SELECT m.id, m.title, m.module, m.position, m.content, m.showtitle, m.params, mm.menuid
FROM ila8e_modules AS m
LEFT JOIN ila8e_modules_menu AS mm
ON mm.moduleid = m.id
LEFT JOIN ila8e_extensions AS e
ON e.element = m.module
AND e.client_id = m.client_id
WHERE m.published = 1
AND e.enabled = 1
AND (m.publish_up = '0000-00-00 00:00:00' OR m.publish_up <= '2018-08-01 09:13:47')
AND (m.publish_down = '0000-00-00 00:00:00' OR m.publish_down >= '2018-08-01 09:13:47')
AND m.access IN (1,1,2,3,6)
AND m.client_id = 1
AND (mm.menuid = 0 OR mm.menuid <= 0)
ORDER BY m.position, m.ordering
In the database the NULL date value is 1000-01-01 00:00:00
but as you can see the query uses 0000-00-00 00:00:00
.
In this file ( https://github.com/joomla-framework/database/blob/2.0-dev/src/Mysqli/MysqliDriver.php#L930 ) the getNullDate()
checks for the NO_ZERO_DATE
SQL Mode. Running the query SELECT @@SESSION.sql_mode;
through Joomla/PHP returns
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
however, running the same query on Sequel Pro or the MySQL CLI it returns
ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION
Notice that the NO_ZERO_DATE
is there when checking directly on MySQL or using a different client but not when using Joomla/PHP.
I believe we need an additional check here.
Commits such as 073aff4 have leaked environment variables used to configure the various CI platforms into the test suite. This essentially changes the testing workflow so that it will only run correctly on a properly configured CI platform, different from the user expectation that the tests should be executable in any environment with the correct settings.
If it is intended to require this type of configuration when executing the tests, these requirements should follow existing conventions for defining constants or env vars and clearly documented for all contributors to use. Otherwise, not documenting this mandatory change will result in unexpected behaviors if the tests are run outside of the configured CI environment.
MSSQL DELETE_ALL tests fail on appveyor see PR #72
tests pass
tests fail
There were 36 errors:
1) Joomla\Database\Tests\DriverSqlsrvTest::test__destruct
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
2) Joomla\Database\Tests\DriverSqlsrvTest::testConnected
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
3) Joomla\Database\Tests\DriverSqlsrvTest::testDropTable
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
4) Joomla\Database\Tests\DriverSqlsrvTest::testEscape with data set #0 (''%_abc123', false, '''%_abc123')
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
5) Joomla\Database\Tests\DriverSqlsrvTest::testEscape with data set #1 (''%_abc123', true, '''%[_]abc123')
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
6) Joomla\Database\Tests\DriverSqlsrvTest::testGetAffectedRows
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
7) Joomla\Database\Tests\DriverSqlsrvTest::testGetCollation
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
8) Joomla\Database\Tests\DriverSqlsrvTest::testGetExporter
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
9) Joomla\Database\Tests\DriverSqlsrvTest::testGetImporter
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
10) Joomla\Database\Tests\DriverSqlsrvTest::testGetNumRows
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
11) Joomla\Database\Tests\DriverSqlsrvTest::testGetTableCreate
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
12) Joomla\Database\Tests\DriverSqlsrvTest::testGetTableColumns
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
13) Joomla\Database\Tests\DriverSqlsrvTest::testGetTableKeys
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
14) Joomla\Database\Tests\DriverSqlsrvTest::testGetTableList
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
15) Joomla\Database\Tests\DriverSqlsrvTest::testGetVersion
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
16) Joomla\Database\Tests\DriverSqlsrvTest::testInsertid
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
17) Joomla\Database\Tests\DriverSqlsrvTest::testLoadAssoc
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
18) Joomla\Database\Tests\DriverSqlsrvTest::testLoadAssocList
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
19) Joomla\Database\Tests\DriverSqlsrvTest::testLoadColumn
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
20) Joomla\Database\Tests\DriverSqlsrvTest::testLoadObject
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
21) Joomla\Database\Tests\DriverSqlsrvTest::testLoadObjectList
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
22) Joomla\Database\Tests\DriverSqlsrvTest::testLoadResult
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
23) Joomla\Database\Tests\DriverSqlsrvTest::testLoadRow
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
24) Joomla\Database\Tests\DriverSqlsrvTest::testLoadRowList
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
25) Joomla\Database\Tests\DriverSqlsrvTest::testExecute
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
26) Joomla\Database\Tests\DriverSqlsrvTest::testRenameTable
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
27) Joomla\Database\Tests\DriverSqlsrvTest::testSelect
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
28) Joomla\Database\Tests\DriverSqlsrvTest::testSetUtf
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
29) Joomla\Database\Tests\DriverSqlsrvTest::testIsSupported
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
30) Joomla\Database\Tests\DriverSqlsrvTest::testUpdateObject
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
31) Joomla\Database\Tests\IteratorSqlsrvTest::testForEach with data set #0 ('title', '#__dbtest', null, 'stdClass', 0, 0, array(stdClass Object (...), stdClass Object (...), stdClass Object (...), stdClass Object (...)), null)
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
32) Joomla\Database\Tests\IteratorSqlsrvTest::testForEach with data set #1 ('title', '#__dbtest', null, 'stdClass', 2, 0, array(stdClass Object (...), stdClass Object (...)), null)
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
33) Joomla\Database\Tests\IteratorSqlsrvTest::testForEach with data set #2 ('title', '#__dbtest', null, 'stdClass', 20, 2, array(stdClass Object (...), stdClass Object (...)), null)
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
34) Joomla\Database\Tests\IteratorSqlsrvTest::testForEach with data set #3 ('title, id', '#__dbtest', 'title', 'stdClass', 0, 0, array(stdClass Object (...), stdClass Object (...), stdClass Object (...), stdClass Object (...)), null)
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
35) Joomla\Database\Tests\IteratorSqlsrvTest::testForEach with data set #4 ('title', '#__dbtest', 'title', 'UnexistingClass', 0, 0, array(), 'InvalidArgumentException')
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
36) Joomla\Database\Tests\IteratorSqlsrvTest::testCount
PHPUnit_Extensions_Database_Operation_Exception: COMPOSITE[DELETE_ALL] operation failed on query:
DELETE FROM jos_dbtest
using args: Array
(
)
[SQLSTATE[42S02]: [Microsoft][ODBC Driver 11 for SQL Server][SQL Server]Invalid object name 'jos_dbtest'.]
C:\projects\database\vendor\joomla\test\src\TestDatabase.php:218
Possible reference items for solving the issues
While rewriting the cms queryies, I tested the affect of wrong input type and it seam that mysql don't care.
Is this normal? Or maybe I did something wrong...
If this expected i would like to suggest to test the type in our db layer and throw an exception if it's wrong.
I see the to string method looking to see if DatabaseQuery::$type is equal to union but it doesn't get set anywhere in the class is this a bug or am I trying to do it wrong?
database/src/DatabaseQuery.php
Line 2475 in 4cda5d7
The function ROW_NUMBER()
seems to be introduced in MySQL 8.
https://www.mysqltutorial.org/mysql-window-functions/mysql-row_number-function/
Though Joomla 4 seems to require MySQL 5.6 as a minimum.
https://developer.joomla.org/news/788-joomla-4-on-the-move.html
Is that feature checked against MySQL version lower to 8 ?
This maybe related with issues regarding the records ordering in the database tables.
e.g. joomla/joomla-cms#23905
For versions lower to 8 it suggests ways to emulate it.
https://www.mysqltutorial.org/mysql-row_number/
Run a prepared statement in a loop.
$ids = [1, 2, 3];
$query
->select('*')
->from('#__table')
->where('id = :id')
->bind(':id', $id, ParameterType::INTEGER);
$db->setQuery($query);
foreach ($ids as $id)
{
$db->loadObject();
}
Rows with specified IDs loaded.
Call to a member function bindParam() on null
PDO and MySQLi.
I'm again not sure whether this is expected or not. One can just move $db->setQuery()
inside the loop to workaround this. However, this is not required when performing queries that are executed with $db->execute()
(e.g. insert/update). To my (limited) understanding, given the nature of prepared statements, DatabaseDriver::freeResult()
should nullify only the result set and not the entire statement.
The Postgresql Driver has Execution errors on insert with the following the unit tests on travis
1) Joomla\Database\Tests\DriverPostgresqlTest::testExecute
Joomla\Database\Exception\ExecutionFailureException:
SQL=INSERT INTO jos_dbtest
(title,start_date,description) VALUES
('testTitle','1970-01-01','testDescription')
/database/src/Postgresql/PostgresqlDriver.php:819
/database/Tests/DriverPostgresqlTest.php:1131
2) Joomla\Database\Tests\DriverPostgresqlTest::testExecutePreparedStatement
Joomla\Database\Exception\ExecutionFailureException:
SQL=INSERT INTO jos_dbtest
(title,start_date,description) VALUES
($1, $2, $3)
/database/src/Postgresql/PostgresqlDriver.php:819
/database/Tests/DriverPostgresqlTest.php:1160
MySQL is not being configured right on Travis. At https://travis-ci.org/joomla-framework/database/jobs/153804058 the tests on the 378 / 626
line are part of the MySQLi iterator and are being skipped. Likewise, all the skips on the first line are the PDO MySQL driver.
// @photodude
in Joomla 4.0 joomla used a strict sql mode
https://github.com/joomla/joomla-cms/pull/12494/files
This was reverted when joomla 4.0 was updated to use the framework database package.
As we know MySql is becoming stricter as the other database systems (postgresql, Mssql) already are.
Example:
In MySQL 5.7.4, the ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE SQL modes were changed so that they did nothing when named explicitly. Instead, their effects were included in the effects of strict SQL mode (STRICT_ALL_TABLES or STRICT_TRANS_TABLES). The intent was to reduce the number of SQL modes with an effect dependent on strict mode and make them part of strict mode itself.
However, the change to make strict mode more strict by including ERROR_FOR_DIVISION_BY_ZERO, NO_ZERO_DATE, and NO_ZERO_IN_DATE caused some problems. For example, in MySQL 5.6 with strict mode but not NO_ZERO_DATE enabled, TIMESTAMP columns can be defined with DEFAULT '0000-00-00 00:00:00'. In MySQL 5.7.4 with the same mode settings, strict mode includes the effect of NO_ZERO_DATE and TIMESTAMP columns cannot be defined with DEFAULT '0000-00-00 00:00:00'. This causes replication of CREATE TABLE statements from 5.6 to 5.7.4 to fail if they contain such TIMESTAMP columns.
The long term plan is still to have the three affected modes be included in strict SQL mode and to remove them as explicit modes in a future MySQL release. But to restore compatibility in MySQL 5.7 with MySQL 5.6 strict mode and to provide additional time for affected applications to be modified, the following changes have been made:
[...]
See https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-8.html#mysqld-5-7-8-sql-mode
Also see discussion in joomla/joomla-cms#16788
When i have many records the Model system call in libraries/src/MVC/Model/ListModel.php the function getTotal() and this call _getListQuery(), this use the getListQuery() in my component model, remove all limit and make a count(*)
of all possible records, so the library can calculate the number of pages.
But if in my model in getListQuery() it's a query with many join, the query that keep the first 20 items (for example) is not a problem, the problem is the count(*) for all records for the pagination.
So the performances are terrible if the items are so many and even the joins.
My solution is add a function in libraries/src/MVC/Model/ListModel.php:
protected function _getPaginationListQuery() {
static $lastStoreId;
$currentStoreId = $this->getStoreId();
if ($lastStoreId != $currentStoreId || empty($this->query)) {
$lastStoreId = $currentStoreId;
if (method_exists($this, "getListPaginationQuery")) {
$this->query = $this->getListPaginationQuery();
} else {
$this->query = $this->getListQuery();
}
}
return $this->query;
}
and change the getTotal in:
public function getTotal() {
// Get a storage key.
$store = $this->getStoreId('getTotal');
// Try to load the data from internal storage.
if (isset($this->cache[$store])) {
return $this->cache[$store];
}
try {
// Load the total and add the total to the internal cache.
$this->cache[$store] = (int) $this->_getListCount($this->**_getPaginationListQuery()**);
} catch (\RuntimeException $e) {
$this->setError($e->getMessage());
return false;
}
return $this->cache[$store];
}
So i can add in my model the function getListPaginationQuery() and insert another query without join or other options that increase the complexity of the same query.
The query in getListPaginationQuery() give the same count of items, but it's best for performance.
(I remove all the Left Join for example or some columns).
If not exist getListPaginationQuery() the library use the standard getListQuery() in component model.
Can this be insert in the next release? thanks.
The following and possibly more changes might not be sufficient regarding the version check:
073aff4#diff-3e927448d9eaafa620c1a995e71ad8d5ab1cae1e56ef4b6a2bd78d68a430ae56R306
ab96e2a#diff-45e47bfc8339fb2db89de46a41ff0b70379e2b570c44ca9685899d898deb099cR317
MySQL who obviously don't use semver (at least not for 8.0.x) have deprecated the display width modifier beginning with version 8.0.17, see https://dev.mysql.com/doc/refman/8.0/en/numeric-type-attributes.html .
I remember from past when I had discovered that after my MSQL had been updated so I had to make PR joomla/joomla-cms#28501 , the display width modifier was part of the type on the 8.0.x version I had before that update.
That means the version check here should be done against version 8.0.17, and that can't be done with a floating point type cast and comparison, it needs to use something like VERSION_COMPARE for that.
Furthermore, MariaDB still support the display width modifier and so behaves like a MySQL < 8.0.17 regarding this. The version check should check this, too.
=> Ping @nibra .
Union queries do not achieve the desired effect
SELECT c.dataindex FROM `simpledatacenter` AS `c` WHERE c.datatype = 'downlink' AND c.dataindex !='' AND c.update_time >'2017-12-13 03:16:29'
UNION
SELECT b.sign FROM `simpledatacenter` AS `b` WHERE b.datatype = 'official' AND b.update_time >'2017-12-13 03:16:06' AND ( SELECT count(*) FROM `simpledatacenter` AS `a` WHERE a.datatype = 'downlink' AND a.dataindex = b.sign) > 0
SELECT c.dataindex FROM `simpledatacenter` AS `c` WHERE c.datatype = 'downlink' AND c.dataindex !='' AND c.update_time >'2017-12-13 03:42:39'
joomla-framework/database Newest
I'm using a database connected by mysqli; It is hoped that the document can be supplemented.
The above content comes from software translation.
$last_update_time = date('Y-m-d H:i:s', time() - 60);
$client = $this->StorageInstance->getClient();
$subQuery = $client->getQuery(true);
$subQuery->from($client->quoteName($this->StorageInstance->getTable(), 'a'));
$subQuery->select('count(*)');
$subQuery->where('a.datatype = ' . $client->quote('downlink'));
$subQuery->where('a.dataindex = b.sign');
$unionQuery = $client->getQuery(true);
$unionQuery->from($client->quoteName($this->StorageInstance->getTable(), 'b'));
$unionQuery->select('b.sign');
$unionQuery->where('b.datatype = ' . $client->quote('official'));
$unionQuery->where('b.update_time >' . $client->quote($last_update_time));
$unionQuery->where('(' . $subQuery . ') > 0');
$mainQuery = $client->getQuery(true);
$mainQuery->from($client->quoteName($this->StorageInstance->getTable(), 'c'));
$mainQuery->select('c.dataindex');
$mainQuery->where('c.datatype = ' . $client->quote('downlink'));
$mainQuery->where('c.dataindex !=' . $client->quote(''));
$mainQuery->where('c.update_time >' . $client->quote($last_update_time));
$mainQuery->union($unionQuery);
var_dump($mainQuery->__toString());
exit();
As per the Framework roadmap "For version 2, we are looking at ... potentially consuming a third party database system."
I don't know what has been discussed so far, but Doctrine DBAL seems like it might be a good candidate for consideration as it is an "Abstraction layer and access library for relational databases. A thin layer on top of PDO with a lot of additional, horizontal functionality."
I would like to extend the bind function parameter 1 and 2 with array syntax like quoteName.
Any opinions?
The LimitableInterface
should be deprecated and its logic moved to the QueryInterface
. All of our query objects (finally) support setting query limits on the query object so this should be the preferred API for setting limits versus setting them via the database driver and setQuery()
.
As a database specialist I sometimes manipulate data directly in the joomla database. Every time I do so, I'm frustrated by the joomla data model. It is complex, redundant, allows invalid data. It looks like a datamodel which hasn't been built by concept, but grown wildly.
I'm sure programming (and data management) would be much easier and less buggy with a proper data model.
I suggest to bring several database specialists together in order to simplyfy the joomla data model for the next major release. I'm ready to work in such a group if I'm needed.
In the CMS we moved our method calls from join('left')
to leftJoin()
I'm not sure if this really makes sense because it's only a alias function to join() so we have small overhead.
Also it makes the API more complex and less maintainable.
Most of the functions are not in the interface which seams to make a problem in IntelliJ IDE so if
we don't remove them they should be in the interface.
Functions for discussion:
[]Join functions
[]where functions
Functions missing in the interface
dateAdd
dateFormat
dump
escape (and alias)
quote (and alias)
quoteName (and alias)
format
Is there a reason why these functions are not in the interface?
no continuous integration testing is currently performed on some database platforms like Oracle, etc
Test against all our database platforms like Oracle, etc
no continuous integration testing is currently performed of the Oracle driver
Apparently, someone has a workaround for testing Oracle DB on travis ci as well https://github.com/cbandy/travis-oracle
an Oracle account is required and the Oracle username and password has to be in the build environment variables either as hidden repository settings or encrypted variables
Tried to bind null values in UPDATE queries with little luck.
Using PHP's null:
$value = null;
$query->bind(':key', $value, ParameterType::NULL);
MySQL: No data supplied for parameters in prepared statement
PDO: HY093, ,
PostgreSQL: ERROR: bind message supplies 0 parameters, but prepared statement "pdo_stmt_00000034" requires 1
Using NULL string:
$value = 'NULL';
$query->bind(':key', $value, ParameterType::NULL);
MySQLi: Incorrect datetime value: 'NULL'
. Using ParameterType::INTEGER
doesn't error but then getting the same result as PDO.
PDO: No errors but value set is incorrect, e.g. on datetime column with NULL
as default it sets 0000-00-00 00:00:00
value.
PostgreSQL: works OK, I think.
Starting with the 1.5.0 tag, all drivers have support for prepared statements and parameterized queries, and in 2.0 this will be a hard requirement because of the new QueryInterface
dictating it. However, the current implementation is dependent on the syntax(es) supported by the underlying driver, meaning at the moment it isn't possible to actually write "properly" abstract queries with parameterized query support (unless an application is only supporting PDO + MySQLi)
INSERT INTO foo (col1, col2) VALUES (?, ?)
) is supported by PDO, MySQLi, and SQL ServerINSERT INTO foo (col1, col2) VALUES (:col1, :col2)
) is supported by PDOINSERT INTO foo (col1, col2) VALUES ($1, $2)
) is supported by PostgreSQL (ext/pgsql
, separate from the PDO driver)So in essence we need some kind of SQL parsing handler in the DatabaseQuery
class. My thought was to have it support the question mark syntax as that one is already supported by most drivers and we only need a PostgreSQL implementation. While discussing in chat @nibra suggested we standardize around the named parameter syntax since it creates an easier to read and parse string.
Whatever the end result, we do need a solution that allows users of our API to not be concerned with these driver specific details (it's OK for now if you're writing single database applications, but because the CMS is using this package in 4.0, it becomes a problem).
Create a query with column value like SELECT 'hello';
print_r($db->setQuery($db->getQuery(true)->select('ala'))->loadColumn());
PHP Warning: Uncaught Joomla\Database\Exception\PrepareStatementFailureException: Unknown column 'ala' in 'field list' in /home/tomash/public_html/database/src/Mysqli/MysqliStatement.php:124
Stack trace:
#0 /home/tomash/public_html/database/src/Mysqli/MysqliDriver.php(860): Joomla\Database\Mysqli\MysqliStatement->__construct(Object(mysqli), 'SELECT ala')
#1 /home/tomash/public_html/database/src/DatabaseDriver.php(1755): Joomla\Database\Mysqli\MysqliDriver->prepareStatement('SELECT ala')
#2 php shell code(1): Joomla\Database\DatabaseDriver->setQuery(Object(Joomla\Database\Mysqli\MysqliQuery))
#3 {main}
thrown in /home/tomash/public_html/database/src/Mysqli/MysqliStatement.php on line 124
Should work.
2.0-dev
I tested it by php -a
and use require '../vendor/autoload.php';
An error screen maybe with a stack trace and an error message that gives any hint what went wrong.
You get a white screen with the text Recursion trying to check if connected.
Checkout from 4.0-dev
The issue seems to be with Joomla\Database\Pdo\PdoDriver::connected()
. That method should check if the connection is alive and for that runs a query, which in turn calls execute(), which again calls connected() which then runs into the recursion condition.
See:
As I understand it, column size and sequence size were two different things up to version 10.
IMO this unit test is unnecessary.
Our test suite tries to unit test a lot of the basic things just to prove functionality but misses proper functional test coverage of much of the API. Also, the current suite structure requires duplicating a lot of the test cases. Look for a better way to structure the test suite and rewrite to better test the package in general.
We should be testing against more versions of the supported database platforms than whatever Travis defaults to. Use https://github.com/doctrine/dbal/blob/master/.travis.yml (and older branch versions which have older version support) as a model for what we should do.
Query with Union does not work at ll.
My example:
Should work.
Joomla 4.0-dev
Is something wrong with do it in the same way as in Joomla3?
I propose a fix:
diff --git a/src/DatabaseQuery.php b/src/DatabaseQuery.php
index 7ee91d0..e912e01 100644
--- a/src/DatabaseQuery.php
+++ b/src/DatabaseQuery.php
@@ -267,6 +267,16 @@ abstract class DatabaseQuery implements QueryInterface
{
$query .= (string) $this->having;
}
+
+ if ($this->union)
+ {
+ $query .= (string) $this->union;
+ }
+
+ if ($this->unionAll)
+ {
+ $query .= (string) $this->unionAll;
+ }
}
if ($this->order)
Ping @mbabker
Per here - we probably want to use debug monitor somehow to disable the query cache. Alternatively in the CMS Level we just use the Connect Event to do this. Not exactly sure what is more logical https://github.com/joomla-framework/database/blob/2.0-dev/src/Mysqli/MysqliDriver.php#L237
We deprecate PreparableInterface and LimitableInterface in 2.0 and trigger 2 E_USER_DEPRECATED on each request.
From performance pov it's not optimal especially as this call is prefixed with @ (Warning suppression). And the CMS will use this several years and can't switch to 3.0 until J5.0.
Can we remove the interface from QueryInterface and merge the function into QueryInterface?
I ask because I want to create a trait to the PreparableInterface but I'm not sure if this is useful if it get removed in 3.0.
We need to allow for no database prefix here:
https://github.com/joomla-framework/database/blob/master/src/DatabaseDriver.php#L401
This causes a b/c problem so we should sync this with a 2.0 release.
the DatabaseDriver function __call()
docblock return type says
// @return string The aliased method's return value or null.
The type indicated here is string
but the comment indicates the type could be null
Additionally, if there are no arguments passed we have a condition returning void
see lines 452-455
return type should not error on Travis
Function return type is not void, but the function is returning void on line 454
The return type should be adjusted to reflect the correct return type.
Offhand I'm not sure if the docblock comment should be changed to
// @return string|null|void The aliased method's return value or null.
or if the return on line 454 should be specified null
with the docblock comment changed to
// @return string|null The aliased method's return value or null.
Please advise for PR to correct this issue
It's not that simple to reproduce this error since you have to simulate a database disconnect.
The following code illustrates the problem, it targets MySQL (but all database drivers are affected since every database rolls back transactions automatically when the connection gets lost).
$db = JFactory::getDbo(); // set up connection (Joomla CMS)
$db->setQuery('CREATE TABLE IF NOT EXISTS transactiontest (pk_value INT, somecol INT)');
$db->execute();
try {
$db->transactionStart();
$db->setQuery('INSERT INTO transactiontest VALUES (1,1)');
$db->execute();
// to simulate a database disconnect set a brakepoint in the debugger on the next line
// and when it get's hit restart your database and then continue debugging when the database is running again
$db->setQuery('INSERT INTO transactiontest VALUES (2,2)');
// the next line should fail but it does not since the automatic reconnect behaviour inside the execute method
// will kick in and reconnect sucessfully and just execute the query without triggering an error
$db->execute();
$db->transactionCommit();
}
catch(RuntimeException $e)
{
// something failed - rollback
$db->transactionRollback();
}
$db->setQuery('SELECT * FROM transactiontest');
$rows = $db->loadObjectList();
// excpected result is zero rows, but it returns 1 row with the values 2,2
var_dump($rows);
No rows inserted into the database
1 row inserted into the database
Doesn't matter - since the issue is independent of OS, database or driver that's used.
All platforms are affected.
There are two solutions to the issue.
remove the automatic reconnect code in the execute() method, this is probably problematic since it
isn't in general a bad idea to do so, intermittend database outages might occur and if one is not inside a transaction the reconnect behaviour is a good thing
only try to reconnect if not inside a transaction - this is actually my proposed solution since
to implement that just one line needs to be changed in the execute method (of all database classes)
// If an error occurred handle it.
if (!$this->cursor)
{
// Get the error number and message before we execute any more queries.
$this->errorNum = $this->getErrorNumber();
$this->errorMsg = $this->getErrorMessage();
// Check if the server was disconnected, but only if not inside a transaction
if ($this->transactionDepth == 0 && !$this->connected())
{
try
{
// Attempt to reconnect.
$this->connection = null;
$this->connect();
}
...
no continuous integration testing is currently performed on some database platforms like MSSQL, etc
Test against all our database platforms like MSSQL, etc
no continuous integration testing is currently performed
I recently read the following
The SQL Server for Linux preview is available as a docker image. Assuming we can setup Travis to protect our access key to the private preview, we could use docker on Travis CI builds to execute against tests SQL Server.
https://www.microsoft.com/en-us/server-cloud/sql-server-on-linux.aspx
(I am aware that the CMS 4.x is dropping MSSQL and that the Framework may follow at some point due to low usage and lack of CI testing)
Joomla issue joomla/joomla-cms#30318
Currently Query monitor logs only query string.
database/src/QueryMonitorInterface.php
Lines 26 to 28 in 4cda5d7
But it also should be able to log bound params. Something like:
public function startQuery(string $sql, array $params = []): void
Do $db->loadObjectList('key', SomeClass::class)
when SomeClass
contains protected properties.
Works.
Trying to access protected property
error.
I'm not sure whether this is expected or not because this works fine on PDO drivers.
Right now the magic getter allows access to all properties. This should be restricted to query elements only; properties such as the database driver don't need to be accessible.
Database::getTableCreate
returns statement with prefixes instead of placeholder #__
:
CREATE TABLE `foo_profile` (
Tested on MysqliDriver
, but likely same results for other drivers where the method is present: SqliteDriver
, OracleDriver
, MysqlDriver
The pdo_oci
extension is largely abandonware and even Doctrine screams about not using it. Therefore I suggest deprecation and removal in 2.0.
The following tests in JTEST_DATABASE_PGSQL_DSN are causing php unit to fail to complete testing;
due to these tests JTEST_DATABASE_PGSQL_DSN has been commented out in phpunit.travis.xml.
These tests could be excluded from the test suit until they are fixed so more tests are completed.
For example, once the tests are excluded the following IteratorPgsqlTest failures are reported
There were 5 failures:
1) Joomla\Database\Tests\IteratorPgsqlTest::testForEach with data set #0 ('title', '#__dbtest', null, 'stdClass', 0, 0, array(stdClass Object (...), stdClass Object (...), stdClass Object (...), stdClass Object (...)), null)
136
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
0 => stdClass Object (
- 'title' => 'Testing'
+ 'title' => 'testTitle'
)
1 => stdClass Object (
- 'title' => 'Testing2'
+ 'title' => 'Testing'
)
2 => stdClass Object (
- 'title' => 'Testing3'
+ 'title' => 'Testing2'
)
3 => stdClass Object (
- 'title' => 'Testing4'
+ 'title' => 'Testing3'
)
+ 4 => stdClass Object (...)
)
/database/Tests/IteratorPgsqlTest.php:137
2) Joomla\Database\Tests\IteratorPgsqlTest::testForEach with data set #1 ('title', '#__dbtest', null, 'stdClass', 2, 0, array(stdClass Object (...), stdClass Object (...)), null)
136
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
0 => stdClass Object (
- 'title' => 'Testing'
+ 'title' => 'testTitle'
)
1 => stdClass Object (
- 'title' => 'Testing2'
+ 'title' => 'Testing'
)
)
/database/Tests/IteratorPgsqlTest.php:137
3) Joomla\Database\Tests\IteratorPgsqlTest::testForEach with data set #2 ('title', '#__dbtest', null, 'stdClass', 20, 2, array(stdClass Object (...), stdClass Object (...)), null)
136
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
0 => stdClass Object (
- 'title' => 'Testing3'
+ 'title' => 'Testing2'
)
1 => stdClass Object (
- 'title' => 'Testing4'
+ 'title' => 'Testing3'
)
+ 2 => stdClass Object (...)
)
/database/Tests/IteratorPgsqlTest.php:137
4) Joomla\Database\Tests\IteratorPgsqlTest::testForEach with data set #3 ('title, id', '#__dbtest', 'title', 'stdClass', 0, 0, array(stdClass Object (...), stdClass Object (...), stdClass Object (...), stdClass Object (...)), null)
136
Failed asserting that two arrays are equal.
--- Expected
+++ Actual
@@ @@
Array (
'Testing' => stdClass Object (...)
'Testing2' => stdClass Object (...)
'Testing3' => stdClass Object (...)
'Testing4' => stdClass Object (...)
+ 'testTitle' => stdClass Object (...)
)
/database/Tests/IteratorPgsqlTest.php:137
5) Joomla\Database\Tests\IteratorPgsqlTest::testCount
153
Failed asserting that 5 matches expected 4.
/database/Tests/IteratorPgsqlTest.php:154
Feature request to extend the database driver ON DUPLICATE KEY functionality
Documentation for each typ of database:
Sample code in CMS:
use Joomla\CMS\Factory;
use Joomla\Database\ParameterType;
$limit = 5;
$db = Factory::getDbo();
$query = $db->getQuery(true)
->select('*')
->from($db->quoteName('#__content'))
->setLimit(':limit')
->bind(':limit', $limit, ParameterType::INTEGER);
$results = $db->setQuery($query)->loadObjectList();
5 items returned
Error without message. Stack trace:
Call stack
--
# | Function | Location
1 | () | JROOT\libraries\vendor\joomla\database\src\Mysqli\MysqliStatement.php:432
2 | Joomla\Database\Mysqli\MysqliStatement->execute() | JROOT\libraries\vendor\joomla\database\src\DatabaseDriver.php:673
3 | Joomla\Database\DatabaseDriver->execute() | JROOT\libraries\vendor\joomla\database\src\DatabaseDriver.php:1336
4 | Joomla\Database\DatabaseDriver->loadObjectList() | JROOT\templates\cassiopeia\index.php:26
5 | require() | JROOT\libraries\src\Document\HtmlDocument.php:671
6 | Joomla\CMS\Document\HtmlDocument->_loadTemplate() | JROOT\libraries\src\Document\HtmlDocument.php:733
7 | Joomla\CMS\Document\HtmlDocument->_fetchTemplate() | JROOT\libraries\src\Document\HtmlDocument.php:543
8 | Joomla\CMS\Document\HtmlDocument->parse() | JROOT\libraries\src\Application\CMSApplication.php:956
9 | Joomla\CMS\Application\CMSApplication->render() | JROOT\libraries\src\Application\SiteApplication.php:754
10 | Joomla\CMS\Application\SiteApplication->render() | JROOT\libraries\src\Application\CMSApplication.php:247
11 | Joomla\CMS\Application\CMSApplication->execute() | JROOT\includes\app.php:63
12 | require_once() | JROOT\index.php:36
Joomla! CMS 4.0-dev nightly, MariaDB 10.3
This works fine using PDO driver.
Is there a chance to have limit set two times for a query ?
Example :
$db = $this->getDb();
$query = $db->getQuery(true);
$query->select('a.id')
->from('#__tests AS a')
->where('a.id > 10');
$db->setQuery($query, 0, 1);
$result = $db->loadResult();
In MysqliDriver::setQuery()
we have this :
if ($query instanceof LimitableInterface && !is_null($offset) && !is_null($limit))
{
$query->setLimit($limit, $offset);
}
and then, in MysqliDriver::execute()
we have :
if ($this->limit > 0 || $this->offset > 0)
{
$sql .= ' LIMIT ' . $this->offset . ', ' . $this->limit;
}
So, my query looks like that :
SELECT a.id FROM abc_tests WHERE a.id > 10 LIMIT 1 LIMIT 0, 1
I'm using the MysqliDriver::lockTable()
method.
With the commits of recent days (nearly 382f9cb), this method throws an exception with this message : "This command is not supported in the prepared statement protocol yet.".
I'm using MariaDB server (I don't know if it is important).
Imo, the LOCK TABLES
statement cannot be prepared.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.