2023-08-10 12:40:53 +00:00
|
|
|
<?php
|
|
|
|
|
|
2024-02-16 22:07:23 +00:00
|
|
|
namespace Wikimedia\Tests\Rdbms;
|
|
|
|
|
|
|
|
|
|
use DatabaseTestHelper;
|
|
|
|
|
use MediaWikiCoversValidator;
|
|
|
|
|
use PHPUnit\Framework\TestCase;
|
|
|
|
|
|
2023-08-10 12:40:53 +00:00
|
|
|
/**
|
|
|
|
|
* @covers \Wikimedia\Rdbms\InsertQueryBuilder
|
|
|
|
|
*/
|
2024-02-16 22:07:23 +00:00
|
|
|
class InsertQueryBuilderTest extends TestCase {
|
2023-08-10 12:40:53 +00:00
|
|
|
use MediaWikiCoversValidator;
|
|
|
|
|
|
|
|
|
|
/** @var DatabaseTestHelper */
|
|
|
|
|
private $db;
|
|
|
|
|
|
|
|
|
|
/** @var InsertQueryBuilderTest */
|
|
|
|
|
private $iqb;
|
|
|
|
|
|
|
|
|
|
protected function setUp(): void {
|
|
|
|
|
$this->db = new DatabaseTestHelper( __CLASS__ . '::' . $this->getName() );
|
|
|
|
|
$this->iqb = $this->db->newInsertQueryBuilder();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
private function assertSQL( $expected, $fname ) {
|
|
|
|
|
$this->iqb->caller( $fname )->execute();
|
|
|
|
|
$actual = $this->db->getLastSqls();
|
|
|
|
|
$actual = preg_replace( '/ +/', ' ', $actual );
|
|
|
|
|
$actual = rtrim( $actual, " " );
|
|
|
|
|
$this->assertEquals( $expected, $actual );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testSimpleInsert() {
|
|
|
|
|
$this->iqb
|
In query builders, use insertInto() and deleteFrom() instead of insert() and delete()
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
2023-09-08 00:06:59 +00:00
|
|
|
->insertInto( 'a' )
|
2023-08-10 12:40:53 +00:00
|
|
|
->row( [ 'f' => 'g', 'd' => 'l' ] );
|
|
|
|
|
$this->assertSQL( "INSERT INTO a (f,d) VALUES ('g','l')", __METHOD__ );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testIgnore() {
|
|
|
|
|
$this->iqb
|
In query builders, use insertInto() and deleteFrom() instead of insert() and delete()
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
2023-09-08 00:06:59 +00:00
|
|
|
->insertInto( 'a' )
|
2023-08-10 12:40:53 +00:00
|
|
|
->ignore()
|
|
|
|
|
->row( [ 'f' => 'g', 'd' => 'l' ] );
|
|
|
|
|
$this->assertSQL( "INSERT IGNORE INTO a (f,d) VALUES ('g','l')", __METHOD__ );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testUpsert() {
|
|
|
|
|
$this->iqb
|
In query builders, use insertInto() and deleteFrom() instead of insert() and delete()
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
2023-09-08 00:06:59 +00:00
|
|
|
->insertInto( 'a' )
|
2023-08-10 12:40:53 +00:00
|
|
|
->row( [ 'f' => 'g', 'd' => 'l' ] )
|
|
|
|
|
->onDuplicateKeyUpdate()
|
|
|
|
|
->uniqueIndexFields( [ 'd' ] )
|
|
|
|
|
->set( [ 'f' => 'm' ] );
|
|
|
|
|
$this->assertSQL(
|
|
|
|
|
"BEGIN; UPDATE a SET f = 'm' WHERE (d = 'l'); INSERT INTO a (f,d) VALUES ('g','l'); COMMIT",
|
|
|
|
|
__METHOD__
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testUpsertWithStringKey() {
|
|
|
|
|
$this->iqb
|
In query builders, use insertInto() and deleteFrom() instead of insert() and delete()
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
2023-09-08 00:06:59 +00:00
|
|
|
->insertInto( 'a' )
|
2023-08-10 12:40:53 +00:00
|
|
|
->row( [ 'f' => 'g', 'd' => 'l' ] )
|
|
|
|
|
->onDuplicateKeyUpdate()
|
|
|
|
|
->uniqueIndexFields( 'd' )
|
|
|
|
|
->set( [ 'f' => 'm' ] );
|
|
|
|
|
$this->assertSQL(
|
|
|
|
|
"BEGIN; UPDATE a SET f = 'm' WHERE (d = 'l'); INSERT INTO a (f,d) VALUES ('g','l'); COMMIT",
|
|
|
|
|
__METHOD__
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testOption() {
|
|
|
|
|
$this->iqb
|
In query builders, use insertInto() and deleteFrom() instead of insert() and delete()
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
2023-09-08 00:06:59 +00:00
|
|
|
->insertInto( 't' )
|
2023-08-10 12:40:53 +00:00
|
|
|
->row( [ 'f' => 'g' ] )
|
|
|
|
|
->option( 'IGNORE' );
|
|
|
|
|
$this->assertSQL( "INSERT IGNORE INTO t (f) VALUES ('g')", __METHOD__ );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testOptions() {
|
|
|
|
|
$this->iqb
|
In query builders, use insertInto() and deleteFrom() instead of insert() and delete()
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
2023-09-08 00:06:59 +00:00
|
|
|
->insertInto( 't' )
|
2023-08-10 12:40:53 +00:00
|
|
|
->row( [ 'f' => 'g' ] )
|
|
|
|
|
->options( [ 'IGNORE' ] );
|
|
|
|
|
$this->assertSQL( "INSERT IGNORE INTO t (f) VALUES ('g')", __METHOD__ );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testExecute() {
|
In query builders, use insertInto() and deleteFrom() instead of insert() and delete()
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
2023-09-08 00:06:59 +00:00
|
|
|
$this->iqb->insertInto( 't' )->rows( [ 'a' => 'b' ] )->caller( __METHOD__ );
|
2023-08-10 12:40:53 +00:00
|
|
|
$this->iqb->execute();
|
|
|
|
|
$this->assertEquals( "INSERT INTO t (a) VALUES ('b')", $this->db->getLastSqls() );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testGetQueryInfo() {
|
|
|
|
|
$this->iqb
|
In query builders, use insertInto() and deleteFrom() instead of insert() and delete()
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
2023-09-08 00:06:59 +00:00
|
|
|
->insertInto( 't' )
|
2023-08-10 12:40:53 +00:00
|
|
|
->ignore()
|
2023-09-11 16:35:25 +00:00
|
|
|
->row( [ 'a' => 'b', 'd' => 'l' ] )
|
|
|
|
|
->caller( 'foo' );
|
2023-08-10 12:40:53 +00:00
|
|
|
$this->assertEquals(
|
|
|
|
|
[
|
2023-10-24 22:49:24 +00:00
|
|
|
'table' => 't',
|
2023-08-10 12:40:53 +00:00
|
|
|
'rows' => [ [ 'a' => 'b', 'd' => 'l' ] ],
|
|
|
|
|
'options' => [ 'IGNORE' ],
|
|
|
|
|
'upsert' => false,
|
|
|
|
|
'set' => [],
|
|
|
|
|
'uniqueIndexFields' => [],
|
2023-09-11 16:35:25 +00:00
|
|
|
'caller' => 'foo',
|
2023-08-10 12:40:53 +00:00
|
|
|
],
|
|
|
|
|
$this->iqb->getQueryInfo() );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testGetQueryInfoUpsert() {
|
|
|
|
|
$this->iqb
|
In query builders, use insertInto() and deleteFrom() instead of insert() and delete()
The design principle for SelectQueryBuilder was to make the chained
builder calls look as much like SQL as possible, so that developers
could leverage their knowledge of SQL to understand what the query
builder is doing.
That's why SelectQueryBuilder::select() takes a list of fields, and by
the same principle, it makes sense for UpdateQueryBuilder::update() to
take a table. However with "insert" and "delete", the SQL designers
chose to add prepositions "into" and "from", and I think it makes sense
to follow that here.
In terms of natural language, we update a table, but we don't delete a
table, or insert a table. We delete rows from a table, or insert rows
into a table. The table is not the object of the verb.
So, add insertInto() as an alias for insert(), and add deleteFrom() as
an alias for delete(). Use the new methods in MW core callers where
PHPStorm knows the type.
Change-Id: Idb327a54a57a0fb2288ea067472c1e9727016000
2023-09-08 00:06:59 +00:00
|
|
|
->insertInto( 't' )
|
2023-08-10 12:40:53 +00:00
|
|
|
->row( [ 'f' => 'g', 'd' => 'l' ] )
|
|
|
|
|
->onDuplicateKeyUpdate()
|
|
|
|
|
->uniqueIndexFields( [ 'd' ] )
|
2023-09-11 16:35:25 +00:00
|
|
|
->set( [ 'f' => 'm' ] )
|
|
|
|
|
->caller( 'foo' );
|
2023-08-10 12:40:53 +00:00
|
|
|
$this->assertEquals(
|
|
|
|
|
[
|
2023-10-24 22:49:24 +00:00
|
|
|
'table' => 't',
|
2023-08-10 12:40:53 +00:00
|
|
|
'rows' => [ [ 'f' => 'g', 'd' => 'l' ] ],
|
|
|
|
|
'upsert' => true,
|
|
|
|
|
'set' => [ 'f' => 'm' ],
|
|
|
|
|
'uniqueIndexFields' => [ 'd' ],
|
|
|
|
|
'options' => [],
|
2023-09-11 16:35:25 +00:00
|
|
|
'caller' => 'foo'
|
2023-08-10 12:40:53 +00:00
|
|
|
],
|
|
|
|
|
$this->iqb->getQueryInfo() );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testQueryInfo() {
|
|
|
|
|
$this->iqb->queryInfo(
|
|
|
|
|
[
|
|
|
|
|
'table' => 't',
|
|
|
|
|
'rows' => [ [ 'f' => 'g', 'd' => 'l' ] ],
|
|
|
|
|
'options' => [ 'IGNORE' ],
|
|
|
|
|
]
|
|
|
|
|
);
|
|
|
|
|
$this->assertSQL( "INSERT IGNORE INTO t (f,d) VALUES ('g','l')", __METHOD__ );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function testQueryInfoUpsert() {
|
|
|
|
|
$this->iqb->queryInfo(
|
|
|
|
|
[
|
|
|
|
|
'table' => 't',
|
|
|
|
|
'rows' => [ [ 'f' => 'g', 'd' => 'l' ] ],
|
|
|
|
|
'upsert' => true,
|
|
|
|
|
'set' => [ 'f' => 'm' ],
|
|
|
|
|
'uniqueIndexFields' => [ 'd' ],
|
|
|
|
|
]
|
|
|
|
|
);
|
|
|
|
|
$this->assertSQL(
|
|
|
|
|
"BEGIN; UPDATE t SET f = 'm' WHERE (d = 'l'); INSERT INTO t (f,d) VALUES ('g','l'); COMMIT",
|
|
|
|
|
__METHOD__
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|