[DDC-3211] Annotation @ORM\Table(name="schema.table") don't generate sql using OCI8 Created: 09/Jul/14  Updated: 12/Jul/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM
Affects Version/s: 2.4.1, 2.4.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Jorge Potosme Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cli, mapping, oci8, oracle, orm, symfony
Environment:

OS: Fedora 20
Web Server: Apache
DBMS: Oracle 12c
Framework: Symfony2
PHP version: 5.5.14
DBMS Driver: OCI8



 Description   

Using Symfony and "doctrine/orm": "2.4.@dev", "doctrine/doctrine-bundle": "1.3.@dev", with OCI8(Oracle Call Interface)
I have an entity
/**
* @ORM\Entity
* @ORM\Table(name="rrhh.usuario")
*/
class Usuario implements UserInterface

{ ... }

When i use de CLI (php app/console doctrine:schema:create --dump-sql) this don't show nothing, the output is empty.

If i change (name="rrhh.usuario") to (name="usuario", schema="rrhh") the CLI show the sql query but without the schema.



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

Duplicates this issue





[DDC-3105] Doctrine Console Error (ORMPurger) Created: 29/Apr/14  Updated: 29/Apr/14

Status: Open
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Carlos Mendoza Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: Cli, schematool


 Description   

In symfony2 the command doctrine:fixtures:load Fails One-To-Many, Self-referencing using Doctrine\Common\DataFixtures\Purger\ORMPurger in example:

class DescriptionArea

{ //.. /** * @ORM\OneToMany(targetEntity="DescriptionArea", mappedBy="parent") */ protected $descriptionAreas; /** * @ORM\ManyToOne(targetEntity="DescriptionArea", inversedBy="descriptionAreas") */ protected $parent; //.. }

Throw error:
[Doctrine\DBAL\DBALException]

An exception occurred while executing 'DELETE FROM prefix_DescriptionArea':

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row: a foreign key constraint fails (sigtec_dev.prefix_DescriptionArea,

CONSTRAINT FK_7265873E727ACA70 FOREIGN KEY (parent_id) REFERENCES prefix_DescriptionArea (id))

Before running the query should delete the index when the table has self-reference.






[DDC-2605] Console command generates entity stubs that break type hinting contracts. Created: 09/Aug/13  Updated: 12/Aug/13

Status: Open
Project: Doctrine 2 - ORM
Component/s: Tools
Affects Version/s: 2.3
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Alex Parker Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: cli, orm, stubs, tools, type-hinting
Environment:

Debian Linux (crunchbang)
PHP 5.4.4-14+deb7u2 (cli)
MySQL Server version: 5.5.31-0+wheezy1 (Debian)


Attachments: PNG File thcontract.png    

 Description   

I've found that the doctrine cli tool seems to break PHP's type hinting contracts in the scenario outlined in the attached diagram, following a process outlined in my stack overflow post here: http://stackoverflow.com/questions/18098552/using-symfony-2-cli-tools-how-can-i-generate-getters-and-setters-with-correct-t

The result is code that throws E_STRICT notices which we are loathe to suppress for CI reasons, e.g: Runtime Notice: Declaration of ... should be compatible with ... in ... line ...

As mentioned I have asked on Stack Overflow to no avail, as well as the FreeNode IRC channels starting with #symfony. The response from #symfony is that this is a doctrine issue, with suggestions being made that my problem is that I am using the CLI tools.

I don't think it would be too difficult to fix this issue. I had a quick look at the Doctrine\ORM\Tools\EntityGenerator class and Doctrine\ORM\Tools\Console\Command\GenerateEntitiesCommand and it looks like it should be possible to find the eldest ancestor definition of a function and honour its type hints.

I am open to this being an implementation issue on my end, but I do feel this may be either a bug or an opportunity to improve the CLI tools as for most other purposes they have been a huge benefit to automating my workflow.

Thanks for your time and consideration.






[DDC-2570] Doctrine CLI Tools - Clear All Cache Created: 24/Jul/13  Updated: 08/Feb/14

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM, Tools
Affects Version/s: 2.3.4
Fix Version/s: 2.x, 2.5

Type: Improvement Priority: Minor
Reporter: Frederick Marcoux Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, cache, orm


 Description   

It would be nice to be able to clear all cache one shot instead of clearing them one after one...

Like this:

root$ ./doctrine orm:clear-cache:all

Instead of:

root$ ./doctrine orm:clear-cache:metadata
root$ ./doctrine orm:clear-cache:result
root$ ./doctrine orm:clear-cache:query






[DDC-2489] Missing semicolon in schema update tool, using dump-sql argument Created: 05/Jun/13  Updated: 08/Sep/13  Resolved: 08/Sep/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM, Tools
Affects Version/s: None
Fix Version/s: 2.4

Type: Bug Priority: Minor
Reporter: Robert-Jan Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: Cli, schematool


 Description   

When executing the schema-tool update script, using the --dump-sql argument (e.g. "app/console doctrine:schema:update --dump-sql" in a symfony2 project), the semicolon behind the last query is missing.



 Comments   
Comment by Guilherme Blanco [ 12/Jun/13 ]

Fixed in https://github.com/doctrine/doctrine2/commit/0d834d0bd4015de2c103a03592c1543399f1b363





[DDC-2486] Getting started does not work with current release Created: 04/Jun/13  Updated: 12/Mar/14  Resolved: 11/Sep/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3.4, 2.4.1
Fix Version/s: 2.4
Security Level: All

Type: Documentation Priority: Minor
Reporter: Julian Picht Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 1
Labels: Cli
Environment:

Ubuntu 12.04



 Description   

The tutorial states: "This tutorial assumes you work with Doctrine 2.3 and above. Some of the code will not work with lower versions."

I'm using 2.3.4

When running "php vendor/bin/doctrine orm:schema-tool:create"

this happens:

PHP Fatal error: Call to undefined method Doctrine\ORM\Tools\Console\ConsoleRunner::createHelperSet() in /var/www/project/cli-config.php on line 5
PHP Stack trace:
PHP 1.

{main}() /var/www/project/vendor/doctrine/orm/bin/doctrine:0
PHP 2. include() /var/www/project/vendor/doctrine/orm/bin/doctrine:4
PHP 3. require() /var/www/project/vendor/doctrine/orm/bin/doctrine.php:31

Fatal error: Call to undefined method Doctrine\ORM\Tools\Console\ConsoleRunner::createHelperSet() in /var/www/project/cli-config.php on line 5

Call Stack:
0.0001 619840 1. {main}

() /var/www/project/vendor/doctrine/orm/bin/doctrine:0
0.0003 632072 2. include('/var/www/project/vendor/doctrine/orm/bin/doctrine.php') /var/www/project/vendor/doctrine/orm/bin/doctrine:4
0.0012 730208 3. require('/var/www/project/cli-config.php') /var/www/project/vendor/doctrine/orm/bin/doctrine.php:31

This is because some commits are not yet in the release. The current GIT version probably works but is not an option for me.



 Comments   
Comment by Benton Jackson [ 11/Jun/13 ]

I'm seeing this problem too. Kinda hard to learn Doctrine when the tutorial is brain dead.

Comment by Benton Jackson [ 11/Jun/13 ]

"CreateHelperSet" appears to be a method in 2.4. I adapted the "2.3 configuring the command line" code to make my "cli-config.php" file read like this, and it appears to work:

<?php
// cli-config.php
require_once "bootstrap.php";

$em = $entityManager;

$helperSet = new \Symfony\Component\Console\Helper\HelperSet(array(
'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($em->getConnection()),
'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em)
));

Comment by Stephen Westman [ 23/Jun/13 ]

Thanks to Benton, I now have a working Doctrine app. I agree that it would be nice to have had this taken care of before release. However, as an old time guerrilla-type programmer, I can do "whatever works"!

Thanks again, Benton!

Comment by Mortensen Cristian [ 25/Aug/13 ]

Thanks Benton!

Comment by Benjamin Eberlei [ 11/Sep/13 ]

2.4 is now released and the tutorial works, sorry for the long disconnect

Comment by Vishal Bandre [ 03/Mar/14 ]

My working cli-config.php with latest fresh doctrine source as on Mar 03 2014.

Windows XP - Access doctrine without using php command like > vendor\bin\doctrine.

<?php // cli-config.php
use Doctrine\ORM\Tools\Console\ConsoleRunner;

// replace with file to your own project bootstrap
require_once 'bootstrap.php';

// replace with mechanism to retrieve EntityManager in your app
// $entityManager = GetEntityManager();

$em = $entityManager;
$helperSet = new \Symfony\Component\Console\Helper\HelperSet(array(
'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($em->getConnection()),
'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em)
));
return ConsoleRunner::createHelperSet($em);

Comment by Igor Timoshenkov [ 11/Mar/14 ]

Hello, everyone.

I am trying to follow the Tutorial, but I am stuck with the cli generation. Here is my cli-config.php file:

<?php
use Doctrine\ORM\EntityManager;
use Doctrine\ORM\Tools\Console\ConsoleRunner;
use Doctrine\ORM\Tools\Setup;

require_once "vendor/autoload.php";

$modelsPath = realpath(_DIR_.'/../model');
$config = Setup::createAnnotationMetadataConfiguration(array($modelsPath), true);

// database configuration parameters
$conn = array(
'driver' => 'pdo_sqlite',
'host' => 'localhost',
'user' => 'root',
'password' => '',
'dbname' => 'someDb',
);

return ConsoleRunner::createHelperSet(EntityManager::create($conn, $config));

Now, when I run

php vendor/bin/doctrine orm:schema-tool:create
or
php vendor/bin/doctrine orm:schema-tool:drop

I get Access denied. What am I doing wrong?

P.S. I am not using Symfony, Doctrine version is 2.4.1.

Comment by Vishal Bandre [ 12/Mar/14 ]

Which db driver are you using?

If you are using sqlite the conn parameters to be used are user, password, path, memory as described on http://docs.doctrine-project.org/projects/doctrine-dbal/en/2.0.x/reference/configuration.html but your connection array is showing wrong settings (these are MYSQL specific). Please check required db driver and try again.

Comment by Marco Pivetta [ 12/Mar/14 ]

Igor Timoshenkov's question was solved at http://stackoverflow.com/q/22336256/347063

Basically, his vendor/bin/doctrine was broken, but running php vendor/doctrine/orm/bin/doctrine worked fine.

Comment by Igor Timoshenkov [ 12/Mar/14 ]

Hi, guys.

Igor Timoshenkov's question was solved at http://stackoverflow.com/q/22336256/347063

My question is not solved.

If you are using sqlite the conn parameters to be used are user, password, path, memory as described on http://docs.doctrine-project.org/projects/doctrine-dbal/en/2.0.x/reference/configuration.html but your connection array is showing wrong settings (these are MYSQL specific). Please check required db driver and try again.

I have corrected the configuration parameters - I needed pdo_mysql, not pdo_sqlite. But the php vendor/bin/doctrine orm:schema-tool:create is still not working. Any ideas what else could that be?

BTW, the link to the configuration should be added to the Tutorial.

Comment by Vishal Bandre [ 12/Mar/14 ]

Will you please share/paste full error message here?

Check for missing db password, etc.





[DDC-2425] Parent entity sometimes fails to load when validating/updating schema. Created: 03/May/13  Updated: 03/May/13  Resolved: 03/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: None
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Trivial
Reporter: Scott Gibson Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: Cli, orm, schematool
Environment:

Debian 6.0.6 x64



 Description   

Should not have reported, was a stupid mistake on my part.






[DDC-2188] DQL arithmetic priority is not considered in expression 'a/(b*c)' Created: 05/Dec/12  Updated: 06/Apr/13  Resolved: 06/Apr/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: DQL, ORM
Affects Version/s: 2.3
Fix Version/s: 2.4
Security Level: All

Type: Bug Priority: Major
Reporter: Mahdi Dehghani Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: Cli, mysql


 Description   

A DQL query that contains an arithmetic expression like 'a/(b*c)' will be compiled to 'a/b*c' in SQL and therefore the result of '100/(2*2)' will be 100, instead of 25.

Note: I have tested it by mysql only



 Comments   
Comment by Marco Pivetta [ 16/Mar/13 ]

Being handled in DDC-2355





[DDC-2161] Moving entity relationship doesn't move foreign key in mysql table Created: 22/Nov/12  Updated: 03/Feb/14  Resolved: 25/Nov/12

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers, ORM
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Alessandro Tagliapietra Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: Cli, mysql
Environment:

Mac OSX, mysql 5.5.28, php 5.4.8, fresh symfony install with doctrine/orm 77d060ab74212919f1eaace72842ea43bf420f43


Attachments: File Argument.php     File Post.php     File Post2.php    
Issue Links:
Reference
relates to DBAL-392 Moving entity relationship doesn't mo... Resolved

 Description   

Edit: moved the bug to the dbal project, please delete this or set as invalid, new bug:

http://www.doctrine-project.org/jira/browse/DBAL-392

------------------------------------------------------

These are the steps I've tried to reproduce the problem:

  • composer create-project symfony/framework-standard-edition path/ 2.1.3
  • edited parameters for mysql db
  • created attached 'Post' entity (note the parent/children fields)
  • updated schema with doctrine:schema:create

I see that the foreign key in phpmyadmin is correctly set to Post.id which is correct.

Now:

  • created another entity 'Argument'
  • moving the children field from 'Post' to 'Argument' removing setters getters into 'Post' and changing target entity field accordingly
  • Updated DB schema (doctrine:schema:update --force)

The situation is now the one you can find in Post2 and Argument attachments.

The problem is that now, the foreign key in Post field it's still on Post.id and not on Argument.id and schema:update says the DB is in sync with the metadata.

Manually deleting the foreign key and running schema:update makes the key being correctly created into Argument.id



 Comments   
Comment by Benjamin Eberlei [ 24/Nov/12 ]

A related Github Pull-Request [GH-234] was opened
https://github.com/doctrine/dbal/pull/234

Comment by Benjamin Eberlei [ 25/Nov/12 ]

On wrong project, see DBAL-392

Comment by Doctrine Bot [ 03/Feb/14 ]

A related Github Pull-Request [GH-234] was closed:
https://github.com/doctrine/common/pull/234





[DDC-2135] Setting column defaults using options in the annotations causes redundant alter statements Created: 09/Nov/12  Updated: 01/May/13  Resolved: 01/May/13

Status: Resolved
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.2
Fix Version/s: 2.3.4
Security Level: All

Type: Bug Priority: Major
Reporter: Cory Comer Assignee: Benjamin Eberlei
Resolution: Duplicate Votes: 0
Labels: Cli, schematool


 Description   

When using the Column annotation on an entity and passing the options parameter to set a default value for a column, the doctrine cli will generate the alter statement every time the schema-tool is run.

This doesn't break the functionality of updating the schema using the cli but when you have multiple entities using default values in this manner it becomes cumbersome to investigate issues during updates that fail and you need to dump the generated sql to examine.

Use case: We have a number of entities that include 'boolean' flags. The data for these entities is inserted into the database through an integration process handled by another application. For all of the flags we want to set a default value of 0 to avoid having to modify the integration scripts when a new flag is added to an entity and the data is not available yet.

Example entity:

/**
 * @ORM\Entity
 * @ORM\Table(name="example")
 */
class Example
{
    
    /**
     * @ORM\Id
     * @ORM\Column(type="integer")
     */
    protected $id;
    
    /** @ORM\Column(type="integer", options={"default" = 0}) */
    protected $disabled;
    
}
$ php bin/doctrine orm:schema-tool:update --dump-sql
ALTER TABLE example CHANGE disabled disabled TINYINT(1) DEFAULT '0' NOT NULL;

This alter statement is generated on every run of the schema-tool even though the schema has already been altered.



 Comments   
Comment by Benjamin Eberlei [ 01/May/13 ]

This is fixed for 2.3.4





[DDC-1983] Incorrect use statement in 25.1.3. Configuration example (Doctrine Console) Created: 15/Aug/12  Updated: 15/Aug/12

Status: Open
Project: Doctrine 2 - ORM
Component/s: Documentation
Affects Version/s: None
Fix Version/s: None

Type: Documentation Priority: Minor
Reporter: Atli Thor Jonsson Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, documentation


 Description   

The code example here:
http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/reference/tools.html#configuration-non-pear

In the second "use" statement it references a "EntityManagerHelper" from the "Doctrine\DBAL\Tools\Console\Helper\" package. However, it does not exist there. It does exist in the "Doctrine\ORM\Tools\Console\Helper\" package though, and replacing it seems to work.






[DDC-1965] Multiple Index fails if index name not specified Created: 02/Aug/12  Updated: 02/Aug/12

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: Pont Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli
Environment:

Ubuntu 11.04, PHP 5.3.6 with Suhosin-patch, Symfony 2.0.15



 Description   

@ORM\Table(name="applications", indexes={@ORM\Index(name="csl_idx", columns=

{"createdAt", "status", "loanType"}), @ORM\Index(name="s_idx", columns={"status"}), @ORM\Index(name="l_idx", columns={"loanType"})})

the above Annotation creates 3 different indexes BUT when:
* @ORM\Table(name="applications", indexes={@ORM\Index(columns={"createdAt", "status", "loanType"}

), @ORM\Index(columns=

{"status"}

), @ORM\Index(columns=

{"loanType"}

)})

index-names not specified Symfony2 schemaUpdate tools shows only the last Index






[DDC-1957] DB -> Entity: Reverse engeniering with two relations between two tables Created: 29/Jul/12  Updated: 29/Jul/12

Status: Open
Project: Doctrine 2 - ORM
Component/s: Mapping Drivers
Affects Version/s: 2.2
Fix Version/s: None
Security Level: All

Type: Bug Priority: Major
Reporter: sky diablo Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli
Environment:

windows 7, php 5.3, symfony 2.1



 Description   

i use the cli from the symfony 2.1 project to reverse from DB to Entity:

php app/console doctrine:mapping:convert xml ./src/Acme/StoreBundle/Resources/config/doctrine/metadata/orm --from-database --force

and i get tis error:

[Doctrine\ORM\Mapping\MappingException]
Property "radUser" in "RadAttribute" was already declared, but it must be declared only once

so i have a table "radUser" with two m:n relations to the same table "radAttributes":

Table radUser:
check => radAttributes
reply => radAttributes

so doctrine reverse mapping try to generate the radAttribute entity with two mapping to radUser with the same field name "radUser", what can i do to prevent this issue ?






[DDC-1945] Cli: orm:validate-schema doesn't validate inheritence map Created: 26/Jul/12  Updated: 23/Jan/13  Resolved: 23/Jan/13

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM, Tools
Affects Version/s: Git Master
Fix Version/s: None
Security Level: All

Type: Bug Priority: Minor
Reporter: Daniel Strøm Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: Cli
Environment:

Debian, Zend Framework 2 with doctrineModule, doctrineORM, ZfcUser and ZfcUserDoctrineORM



 Description   

ZfcUser\Entity\User is a mapped super class
ZfcUserDoctrineORM\Entity\User is not

When extending anyone of them, the cli command orm:validate-schema returns true. It should not return true if its not a mapped super class.



 Comments   
Comment by Marco Pivetta [ 23/Jan/13 ]

Not related to the ORM itself.





[DBAL-819] Schema-tools does not work on multiple Oracle's schemas Created: 21/Feb/14  Updated: 22/Feb/14

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

Type: Bug Priority: Major
Reporter: Antoine Descamps Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: Cli, oracle, orm, schematool
Environment:

DB: Oracle 11g



 Description   

The schema-tools, used via the CLI, is not able to detect schema's changes when working on multiple schemas.

For instance, the ORM is configured with a "global" Oracle's user, having permissions on every schemas. To specify which entities belong to which schema, I've prefixed the table name with the corresponding schema.

When trying to do the following command:

orm:schema-tool:update --dump-sql

Doctrine returns me the following message:

Nothing to update - your database is already in sync with the current entity metadata.

If, instead of using the "global" user in the Doctrine's configuration, I set the user of the specific schema I'm trying to generate a table on based from an entity, it works.



 Comments   
Comment by Steve Müller [ 21/Feb/14 ]

Moved this to DBAL for now. It seems to be related to schema prefixed table names not being evaluated in the platforms when generating the SQL for reverse engineering the database schema.

Comment by Steve Müller [ 22/Feb/14 ]

Antoine Descamps Okay after having investigated on this in detail and thinking about the possibilities we have to find a solution for this, I came to the following conclusion:
ORM's schema tool and DBAL's schema introspection are designed to be bound to what Doctrine defines as "database" for each platform. This is the scope of the whole operation. In case of Oracle it is the "user". You cannot break out of this scope in any way as the current DBAL implementation is not designed for a "complete" schema introspection and therefore does not allow it at some points. Fully understanding your concern I am afraid we cannot find a reasonable solution for your use case at this point in development (2.x). Furthermore there is a good reason for limiting the schema introspection to a certain layer. If the schema tool would introspect the "complete" schema without regard to the database it is connected to, it would suggest a lot of schema changes from other databases that do not belong to the context of the entity manager / database. This behaviour would even cause a lot more annoyance to users as it is the default use case that users are only interested in one database per entity manager.
Also this problem is completely independant from your mapping definitions. So it doesn't matter whether you prefix your table names or not. When running the "update" operation on the schema tool, it is the online schema introspection part that is preventing the schema tool from behaving as you would wish.
Changing the schema introspection behaviour in DBAL would completely break BC and is at some places in the code not even possible without changing the API.
I am sorry that I have to disappoint you with this conclusion but we I am afraid we cannot do anything about your issue until we start developing 3.x. We might reevaluate your use case their and see what we can do.





[DBAL-764] Provide a reference of the portable Column types and options Created: 04/Jan/14  Updated: 15/Feb/14  Resolved: 15/Feb/14

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.4.2
Fix Version/s: 2.5
Security Level: All

Type: Documentation Priority: Minor
Reporter: Frederic G. MARAND Assignee: Steve Müller
Resolution: Fixed Votes: 0
Labels: Cli, documentation

Attachments: File SchemaReferenceCommand.php    

 Description   

One difficulty I had with the existing documentation and tools for DBAL was the lack of a reference for what the valid values were (e.g. "notnull" instead of "not null").

See http://docs.doctrine-project.org/projects/doctrine-dbal/en/latest/reference/schema-representation.html for example: some values are given, but there is no reference list, and anything put just in documentation would incur the risk of not remaining updated.

So I tried to guess-generate the information from the code, like this: https://gist.github.com/FGM/8261606 (also attached).

Unless an equivalent already exists somewhere, I think it could be useful to have something like this in upcoming releases.



 Comments   
Comment by Steve Müller [ 09/Jan/14 ]

Documentation supplied in PR: https://github.com/doctrine/dbal/pull/502
Please give a shout if something is missing, wrong, arguable or what...

Comment by Frederic G. MARAND [ 09/Jan/14 ]

Glad to see so much information in your PR. Did you create it from scratch or was it available elsewhere ?

Also, since the project seems to have some difficulty keeping up with "guide"-type documentation vs code evolutions, wouldn't it be feasible to have most of this information be generated from code (or phpdoc), to have it be automatically maintained when code changes ?

Comment by Steve Müller [ 09/Jan/14 ]

Frederic G. MARAND I created it from scratch as you requested in this ticket. We are aware the DBAL documentation isn't in the best shape, but we are working on it step by step. Please bare with us if it takes some time to catch up all the missing things.
An API documentation is always autogenerated and published automatically on the Doctrine website: http://www.doctrine-project.org/api/dbal/2.4/index.html

Comment by Frederic G. MARAND [ 09/Jan/14 ]

OK, i was afraid it was somewhere and I had missed it. Beyond that, don't you think it would be a good idea to have such lists of information be maintained as phpdoc rather than in the doc sources, and exported instead of being types. This would allow such commands as the one I had imagined (obviously better done).

Comment by Doctrine Bot [ 08/Feb/14 ]

A related Github Pull-Request [GH-502] was closed:
https://github.com/doctrine/dbal/pull/502

Comment by Steve Müller [ 15/Feb/14 ]

Fixed in commit: https://github.com/doctrine/dbal/commit/6adc9ee1cb51e4ffef9811cf1d63de152824dd0d





[DBAL-367] Reverse engnering do not work with Oracle DB Created: 18/Oct/12  Updated: 21/Nov/13  Resolved: 21/Nov/13

Status: Resolved
Project: Doctrine DBAL
Component/s: Drivers, Schema Managers
Affects Version/s: 2.3
Fix Version/s: 2.5

Type: Bug Priority: Major
Reporter: Zelenin Alexandr Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: Cli, oracle, schematool
Environment:

PHP 5.3.3-1ubuntu9.10 with Suhosin-Patch (cli) (built: Feb 11 2012 06:21:15)
oci8-1.4.7 as PHP extension builded from pecl repository with instantclient-basic-linux.x64-11.2.0.3.0.zip and instantclient-sdk-linux.x64-11.2.0.3.0.zip
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production



 Description   
$ doctrine orm:convert-mapping --filter="ms$ions" xml .

  [Doctrine\DBAL\DBALException]
  Unknown database type binary_float requested, Doctrine\DBAL\Platforms\OraclePlatform may not support it.

cli-config.php:


use Doctrine\Common\Annotations\AnnotationReader;
use Doctrine\Common\Annotations\AnnotationRegistry;

require_once 'Doctrine/Common/ClassLoader.php';

define('APPLICATION_ENV', "development");
error_reporting(E_ALL);

$classLoader = new \Doctrine\Common\ClassLoader('Doctrine');
$classLoader->register();

$config = new \Doctrine\ORM\Configuration();
$config->setProxyDir(__DIR__);
$config->setProxyNamespace('Proxies');

$config->setAutoGenerateProxyClasses((APPLICATION_ENV == "development"));

AnnotationRegistry::registerFile("Doctrine/ORM/Mapping/Driver/DoctrineAnnotations.php");
$reader = new AnnotationReader();
$driverImpl = new \Doctrine\ORM\Mapping\Driver\AnnotationDriver($reader, array(__DIR__ . "/../php/ru/niifhm/bioinformatics/biodb/model"));
$config->setMetadataDriverImpl($driverImpl);

if (APPLICATION_ENV == "development") {
    $cache = new \Doctrine\Common\Cache\ArrayCache();
} else {
    $cache = new \Doctrine\Common\Cache\ApcCache();
}

$config->setMetadataCacheImpl($cache);
$config->setQueryCacheImpl($cache);

$connectionOptions = array(
    'driver'   => 'oci8',
    'host'     => 'host.name',
    'dbname'   => 'db.name',
    'user'     => 'user.name',
    'password' => 'user.password'
);

$em = \Doctrine\ORM\EntityManager::create($connectionOptions, $config);
$platform = $em->getConnection()->getDatabasePlatform();
$platform->registerDoctrineTypeMapping('enum', 'string');

$em->getConfiguration()->setMetadataDriverImpl(
    new \Doctrine\ORM\Mapping\Driver\DatabaseDriver(
        $em->getConnection()->getSchemaManager()
    )
);

$helperSet = new \Symfony\Component\Console\Helper\HelperSet(array(
    'db' => new \Doctrine\DBAL\Tools\Console\Helper\ConnectionHelper($em->getConnection()),
    'em' => new \Doctrine\ORM\Tools\Console\Helper\EntityManagerHelper($em)
));


 Comments   
Comment by Marco Pivetta [ 23/Jan/13 ]

Formatting

Comment by Steve Müller [ 07/Nov/13 ]

Should be fixed with following PR:

https://github.com/doctrine/dbal/pull/405

Comment by Doctrine Bot [ 13/Nov/13 ]

A related Github Pull-Request [GH-405] was closed:
https://github.com/doctrine/dbal/pull/405





[DBAL-346] Generated schema fails on MySQL (BLOB/TEXT cant have DEFAULT value) Created: 19/Sep/12  Updated: 20/Sep/12  Resolved: 20/Sep/12

Status: Resolved
Project: Doctrine DBAL
Component/s: Schema Managers
Affects Version/s: 2.2.2
Fix Version/s: 2.3
Security Level: All

Type: Bug Priority: Major
Reporter: Sascha Ahmann Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: Cli, schematool
Environment:

Symfony 2.1.x (dev/master), Doctrine 2.2.3, MySQL 5.5.x



 Description   

In my symfony 2.1 project i was including JMSPaymentCoreBundle and did the vanilla installation.

After that i ran

php app/console doctrine:schema:update --dump-sql
php app/console doctrine:schema:update --force

A lot of schema updates were done. I ran it again, and two schema updates were still showing up.
Running the command again, and they still show up.

I then tried to run the two schema updates against my database and MySQL complains with the following error:

Error: 1101 - BLOB/TEXT column 'extended_data' can't have a default value

According to the Documentation BLOB/TEXT indeed cannot have default values. I am not sure why Doctrine thinks it has to set this default value.

The statements look like this:

sascha@debian:/var/www/myproject/Symfony$ php app/console doctrine:schema:update --dump-sql
ALTER TABLE payment_instructions CHANGE extended_data extended_data LONGTEXT NOT NULL COMMENT '(DC2Type:extended_payment_data)';
ALTER TABLE financial_transactions CHANGE extended_data extended_data LONGTEXT DEFAULT NULL COMMENT '(DC2Type:extended_payment_data)'

I already reported this problem in the JMSPaymentCoreBundle Issue Queue where i then was referred to over here.

Also, i am not sure if Doctrine DBAL is the best match for this issue, so if it is wrong please move it to the right project issue queue.

Thank you very much and best of Regards!
Sascha






Generated at Sat Aug 23 01:47:51 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.