[DBAL-948] [GH-635] Update SQLSrvStatement.php Created: 22/Jul/14  Updated: 22/Jul/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of bouland:

Url: https://github.com/doctrine/dbal/pull/635

Message:

Hi,

I would like to exec a stored procedure with multi result so I think i need that :
http://msdn.microsoft.com/en-us/library/cc296167(v=sql.105).aspx

Is it possible to add specific behavior in general DBAL ?
It is my first pull request, feel free to explain me where I m doing wrong.

Rgds,
Simon






[DBAL-947] [GH-634] Transaction object definition Created: 21/Jul/14  Updated: 21/Jul/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of BenMorel:

Url: https://github.com/doctrine/dbal/pull/634

Message:

To move forward with the Transaction Object, here is an alternative proposal to #571.

This keeps the same basic idea, but now `createTransaction()` returns a `TransactionDefinition` object, which is configurable, and has a `begin()` method that starts the underlying transaction and returns the `Transaction` object:

$tx = $em->createTransaction() // TransactionDefinition
->withIsolationLevel(Connection::TRANSACTION_SERIALIZABLE) // TransactionDefinition
->begin(); // Transaction

I think that this implementation checks all the boxes:

  • Clear separation between the Transaction and its Definition
  • Once the Transaction is created, its Definition is set and cannot be changed
  • No risk to forget to call `begin()`: if you do, you'll deal with a TransactionDefinition and just get a call to undefined method if you try to `commit()` it. Plus, your IDE will be able to warn you while coding.

And needless to say, we're still keeping 100% BC compatibility.

What do you think?






[DBAL-946] Array type with non ascii chars Created: 21/Jul/14  Updated: 21/Jul/14  Resolved: 21/Jul/14

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Саша Стаменковић Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

This is the result I get in database "a:48:{s:8:"distance";s:2:"37";s:9:"Reykjav" after persisting array with value Reykjavík.

As you can see, it is cut on í letter.



 Comments   
Comment by Саша Стаменковић [ 21/Jul/14 ]

I cant post code to reproduce this issues, looks like response I get from API have some strange encoding.

Comment by Marco Pivetta [ 21/Jul/14 ]

The values are likely truncated because of the db-side encoding.

Marking as invalid unless there's a test case to reproduce the issue with utf-8 encoding.





[DBAL-945] [GH-633] Db2altercolumnsyntaxbug Created: 20/Jul/14  Updated: 20/Jul/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of rehfeldchris:

Url: https://github.com/doctrine/dbal/pull/633

Message:

fix for http://www.doctrine-project.org/jira/browse/DBAL-944






[DBAL-944] db2 alter column produces invalid sql syntax Created: 20/Jul/14  Updated: 20/Jul/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: chris rehfeld Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

db2 v10.5 centos 6.5 64



 Description   

The "alter column" sql produced is always incorrect.

Example entity

Widget3.php
<?php
/**
 * @ORM\Entity
 **/
class Widget3
{
    /** @ORM\Id @ORM\Column(type="integer") @ORM\GeneratedValue **/
    protected $id;

    /** @ORM\Column(type="string", length=20) **/
    private $str;
}

orm:schema-tool:create produces:
CREATE TABLE Widget3 (id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL, str VARCHAR(20) NOT NULL, PRIMARY KEY(id));

If you then change the entity like so:

Widget3.php
    /** @ORM\Column(type="string", length=100) **/
    private $str;
}

If you then run orm:schema-tool:update, it will try to run:

ALTER TABLE WIDGET3 ALTER STR str VARCHAR(100) NOT NULL;

which is invalid sql. It should be
ALTER TABLE WIDGET3 ALTER COLUMN STR SET DATA TYPE VARCHAR(100);

This renders the schema-tool inoperable in many scenarios, and causes a large portion of the db2 functional tests to fail.



 Comments   
Comment by chris rehfeld [ 20/Jul/14 ]

pull request https://github.com/doctrine/dbal/pull/633





[DBAL-943] dbal db2 platform uses incorrect column modification strategy for clob Created: 20/Jul/14  Updated: 20/Jul/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Critical
Reporter: chris rehfeld Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

db2 v10.5 centos 6.5



 Description   

db2 only allows certain column types to be used in an ALTER TABLE ALTER COLUMN myCol ... type statement.

Example entity

Widget2.php
<?php
/**
 * @ORM\Entity
 **/
class Widget
{
    /** @ORM\Id @ORM\Column(type="integer") @ORM\GeneratedValue **/
    protected $id;

    /** @ORM\Column(type="string") **/
    private $str;
}

orm:schema-tool:create produces:
CREATE TABLE Widget2 (id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL, str VARCHAR(255) DEFAULT NULL, PRIMARY KEY(id));

If you then change the column type from string to text via ...

Widget2.php
    /** @ORM\Column(type="text") **/
    private $str;

... and you then run orm:schema-tool:update, it will try to run:

ALTER TABLE WIDGET2 ALTER STR str CLOB(1M) NOT NULL;

The sql syntax is wrong, but that's a different issue I'll address elsewhere.Lets assume it's fixed to be proper syntax:
ALTER TABLE WIDGET2 ALTER COLUMN str SET DATA TYPE CLOB(1M) ALTER COLUMN str SET NOT NULL;

This triggers sql error code -190, sqlstate 42837
http://www-01.ibm.com/support/knowledgecenter/SSEPEK_10.0.0/com.ibm.db2z10.doc.codes/src/tpc/n190.dita

Because the from type => to type isn't valid. This link:
http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.1.0/com.ibm.db2.udb.admin.doc/doc/r0000888.htm?lang=en
seems to list the valid alterations.

I'm guessing that a different strategy needs to be used; where we drop the old column, and create the new one in such scenarios. This could cause unexpected data loss though.






[DBAL-942] [GH-632] Add test to verify null cast in boolean type Created: 18/Jul/14  Updated: 18/Jul/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of tiagobrito:

Url: https://github.com/doctrine/dbal/pull/632

Message:

This test verify how null values are casted to boolean values in PostgresPlatform.

NULL values are wrongly casted when flag *useBooleanTrueFalseStrings* is ```true```






[DBAL-941] [GH-631] updated PDO_SQLSRV connection to use driverOptions in prepare-function Created: 18/Jul/14  Updated: 18/Jul/14

Status: Open
Project: Doctrine DBAL
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

This issue is created automatically through a Github pull request on behalf of jaylinski:

Url: https://github.com/doctrine/dbal/pull/631

Message:

it seems that the `PDO::prepare` `$driver_options` param was never used.
in order to use the `PDOStatement::rowCount` function, the connection to an sql-server has to be established with the following params:
```
$connectionParams = array(
'host' => $cfgHostName,
'port' => $cfgPort,
'dbname' => $cfgDatabase,
'user' => $cfgUser,
'password' => $cfgPassword,
'driver' => 'pdo_sqlsrv',
'driverOptions' => array(
PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL,
PDO::SQLSRV_ATTR_CURSOR_SCROLL_TYPE => PDO::SQLSRV_CURSOR_STATIC
)
);
```
the `driverOptions`-array is essential.
see http://msdn.microsoft.com/en-us/library/ff628176.aspx and http://at2.php.net/manual/de/pdo.prepare.php

with the follwing commit, the driver options are used by the PDO_SQLSRV prepared statements.
maybe there's a better way to implement this. please share your opinion on this fix.






[DBAL-940] ORDER BY with LIMIT in SQL Server does not work correctly Created: 17/Jul/14  Updated: 17/Jul/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: M.K. Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

SQL Server


Issue Links:
Reference
relates to DBAL-927 [GH-622] improved sqlserver 'doModify... Resolved

 Description   

The function doModifyLimitQuery() in Doctrine\DBAL\Platforms\SQLServerPlatform does work correctly.

It removes the user generated ORDER BY (gets moved to OVER clause), but does not apply an ORDER BY on the row number created with ROW_NUMBER().

$orderBy = stristr($query, 'ORDER BY');

//Remove ORDER BY from $query (including nested parentheses in order by list).
$query = preg_replace('/\s+ORDER\s+BY\s+([^()]+|\((?:(?:(?>[^()]+)|(?R))*)\))+/i', '', $query);

$format  = 'SELECT * FROM (%s) AS doctrine_tbl WHERE doctrine_rownum BETWEEN %d AND %d';

The last format string should be:

$format  = 'SELECT * FROM (%s) AS doctrine_tbl WHERE doctrine_rownum BETWEEN %d AND %d ORDER BY doctrine_rownum';


 Comments   
Comment by Marco Pivetta [ 17/Jul/14 ]

Possible relation with DBAL-927





[DBAL-939] schema update doesnt detect boolean type correctly Created: 16/Jul/14  Updated: 20/Jul/14

Status: Open
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: chris rehfeld Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None
Environment:

centos 6 64, db2 luw10.5



 Description   

*edited*

Dbal for db2 doesn't seem to be able to differentiate between a smallint and a boolean field on db2. If I make an entity which has a boolean field, it will create a table using type smallint. If I later try to update the schema, it will detect the column in the table as a small int, not a boolean. So, it will produce sql update statements to change the type from smallint to smallint, which is obviously unnecessary. I understand db2 doesn't have a boolean type, but it would be nice if dbal realized that a smallint is essentially already a dbal boolean.

Additionally, the update statement is invalid syntax and fails, although this is probably a separate issue.

Example entity

Widget.php
<?php
/**
 * @ORM\Entity
 **/
class Widget
{
    /** @ORM\Id @ORM\Column(type="integer") @ORM\GeneratedValue **/
    protected $id;

    /** @ORM\Column(type="boolean", nullable=false) **/
    private $isGoat;
}

orm:schema-tool:create produces:
CREATE TABLE Widget (id INTEGER GENERATED BY DEFAULT AS IDENTITY NOT NULL, isGoat SMALLINT NOT NULL, PRIMARY KEY(id));

If you then run orm:schema-tool:update, it will try to run:

ALTER TABLE WIDGET ALTER ISGOAT isGoat SMALLINT NOT NULL; CALL SYSPROC.ADMIN_CMD ('REORG TABLE WIDGET');

but no column alteration is obviosuly needed.

So in summary, smallint to boolean type mapping isn't realized, causing the update command to think it needs to change the type of the column.






Generated at Tue Jul 22 11:36:03 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.