[DBAL-75] SchemaTool->getDropSchemaSql ignores schema name Created: 23/Nov/10  Updated: 12/Dec/10  Resolved: 12/Dec/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.0-RC4
Fix Version/s: 2.0-RC5

Type: Bug Priority: Minor
Reporter: Art Hundiak Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

NA


 Description   

When including the schema name as part of the table name, i.e.

/**
 * @Entity
 * @Table(name="ayso.players")
 */
class PlayerItem

SchemaTool->getDropSchemaSql returns "DROP TABLE players" instead of "DROP TABLE ayso.players"

Furthermore, SchemaTool->getUpdateSchemaSql() always returns CREATE TABLE ayso.players followed by DROP TABLE players. It thinks there are two different tables.

Also, the online document still indicates that @Table accepts 'schema' as an attribute.

 Comments   
Comment by Benjamin Eberlei [ 12/Dec/10 ]

Moved to DBAL, its a DBAL issue.

Comment by Benjamin Eberlei [ 12/Dec/10 ]

Fixed in DBAL master, will be included for RC5. Then linked against ORM RC2




[DBAL-73] Could not convert database value "b:0;" to Doctrine Type object Created: 06/Dec/10  Updated: 12/Dec/10  Resolved: 12/Dec/10

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.0-RC1-RC3
Fix Version/s: 2.0-RC5

Type: Bug Priority: Major
Reporter: Marcus Speight Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None

Attachments: File Setting.php    

 Description   

The following class when value is set to false causes "Could not convert database value "b:0;" to Doctrine Type object" exception when loading the entity.

/** @orm:Entity */
class MyClass
{
/**

  • @orm:Column(name="value", type="object")
    */
    public $value;
    }

 Comments   
Comment by Benjamin Eberlei [ 06/Dec/10 ]

From the PHP manual about unserialize():

In case the passed string is not unserializeable, FALSE is returned and E_NOTICE is issued.

The solution: Use NULL instead of false

Comment by Marcus Speight [ 06/Dec/10 ]

But the string "b:0;" is unserializable it returns false. Also from the php manual on unserialize

FALSE is returned both in the case of an error and if unserializing the serialized FALSE value. 
It is possible to catch this special case by comparing str with serialize(false) or by catching the issued E_NOTICE.

I've submitted a pull request that handles it correctly.

Comment by Benjamin Eberlei [ 06/Dec/10 ]

I know, but this type is called "object", so setting it to false makes no sense. Setting it to null makes sense though.

I know that b:0; is false, but why do you set it to false anyways? Objects are either null or an instance of the object. Never false.

Comment by Marcus Speight [ 06/Dec/10 ]

I'm storing settings in a database. using a Namespace, Key => Value triplet. I don't know what might be stored in the value part. Currently strings, NULL and boolean data are stored. Using object seem to be the best approach. (ArrayTypes have the same problem).

If you think a different type would be better then please let me know.

Comment by Benjamin Eberlei [ 06/Dec/10 ]

how is such a triplet only b:0; ? or is your entity the tripplet and the variable that fails is the value?

Comment by Marcus Speight [ 06/Dec/10 ]

I've added my entity. The entity is the triplet. And it is the value that fails if false is stored.
It allows me to store the value(false) but the throws an exception on loading the entity. It should allow the loading of the value(false) or disallow the storing of a false value.

Comment by Benjamin Eberlei [ 12/Dec/10 ]

Although this should really be just array and object, not strange false types i added this patch to prevent future reports of this as a problem. The loosely typed language PHP can go with null or false, so why throw people stones in their way.




[DBAL-74] OracleSchemaManager - incorrectly detected the length of the string columns Created: 07/Dec/10  Updated: 12/Dec/10  Resolved: 12/Dec/10

Status: Resolved
Project: Doctrine DBAL
Component/s: None
Affects Version/s: 2.0.0-RC1-RC3
Fix Version/s: 2.0-RC5

Type: Bug Priority: Major
Reporter: Miloslav "adrive" Kmet Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

When I create a VARCHAR2 column with the length specified in char units (VARCHAR2(10 CHAR)) instead of the default byte, the metadata stored in all_tab_columns -> data_length is not 10, but 40. It is better to use char_length instead of data_length. Char_length is the same wheter the size unit is in CHAR or BYTE.

It is neccessary for me to use CHAR instead of the default BYTE, because I am using unicode charset.

 Comments   
Comment by Miloslav "adrive" Kmet [ 07/Dec/10 ]

https://github.com/milokmet/dbal/commit/a5087e8e229bfd2cde947e1d387ebe2e2b122b85

Comment by Benjamin Eberlei [ 07/Dec/10 ]

Can I appoint you to Doctrine's Oracle specialist?

Thank you very much, I will merge that as soon as i have time.

Comment by Benjamin Eberlei [ 12/Dec/10 ]

Merged




[DBAL-71] Call to undefined function Created: 05/Dec/10  Updated: 12/Dec/10  Resolved: 12/Dec/10

Status: Resolved
Project: Doctrine DBAL
Component/s: Platforms
Affects Version/s: 2.0.0-BETA2, 2.0.0-BETA3, 2.0.0-BETA4, 2.0.0-RC1-RC3
Fix Version/s: 2.0-RC5

Type: Bug Priority: Trivial
Reporter: Johannes Schmitt Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

There is a "new" missing in AbstractPlatform on line 1421:

throw \InvalidArgumentException('Invalid foreign key action: ' . $upper);

 Comments   
Comment by Benjamin Eberlei [ 12/Dec/10 ]

Fixed




Generated at Mon May 27 02:55:00 UTC 2013 using JIRA 5.2.7#850-sha1:b2af0c8dc8537b36121c6a579fabbdf79fc919e5.