[DDC-1985] Call to undefined method ProxyException::proxyDirectoryNotWritable Created: 16/Aug/12  Updated: 17/Aug/12  Resolved: 17/Aug/12

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.2.3
Fix Version/s: 2.3
Security Level: All

Type: Bug Priority: Major
Reporter: Mark van der Velden Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

I think it's fairly self explanatory, didn't supply a patch since I had no idea what text you wanted there

PHP Fatal error:  Call to undefined method Doctrine\ORM\Proxy\ProxyException::proxyDirectoryNotWritable() in .../orm/lib/Doctrine/ORM/Proxy/ProxyFactory.php on line 193


 Comments   
Comment by Guilherme Blanco [ 17/Aug/12 ]

This issue is already fixed in master





[DDC-1919] Doctrine fails to escape entity with reserved name in various situations Created: 10/Jul/12  Updated: 19/Jul/12  Resolved: 11/Jul/12

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

Type: Bug Priority: Major
Reporter: Klaus Silveira Assignee: Benjamin Eberlei
Resolution: Invalid Votes: 0
Labels: None
Environment:

MySQL



 Description   

I have submitted a PR here, fixing part of this issue: https://github.com/doctrine/dbal/pull/166

However, it fails when UPDATE or INSERT is used. I'm using a very simple, and common, entity name: Group. Doctrine is failing to escape this in various situations, causing queries to fail in MySQL due to reserved keywords.



 Comments   
Comment by Marco Pivetta [ 11/Jul/12 ]

Can you try using the quoting strategy in master? By defining an '@Table(name="`Group`")' on your entity you should be able to fix this issue by yourself... Anyway, this is only available in latest master.
Please give it a try and let us know.

Comment by Klaus Silveira [ 11/Jul/12 ]

That hack, of course, fixes the problem. However, Doctrine is failing to escape entities with reserved keywords in various different situations and this should be a major problem, specially since there are many keywords that are common table names. Having to change the table name or escape the table name manually is not the best solution.

I have look through the code but could not find out why getQuotedTableName() is failing to quote the table name "Group". I fixed the other problem, involving schema creation, but this one i couldn't fix. That's why i'm opening the issue, hoping someone with more experience in the ORM codebase manages to fix it.

Comment by Marco Pivetta [ 11/Jul/12 ]

Klaus Silveira, doctrine won't quote (at least with the default strategy) a table called "Group". The default strategy will look for the sorrounding "`" ("`Group`").
Is it still failing to quote something in latest master? Can you write a simple example of a failure you are getting?

Comment by Klaus Silveira [ 11/Jul/12 ]

The failure is caused when querying anything related to an entity wich it's name is a reserved keyword, for example, an entity called "Group". I expected Doctrine to quote such table names.

Comment by Marco Pivetta [ 11/Jul/12 ]

Klaus Silveira did you put an @Table(name="`Group`") in it?

Comment by Marco Pivetta [ 11/Jul/12 ]

Please note that

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
@Table(name="Group")

and

Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
@Table(name="`Group`")

are quite different. That's why I'm asking

Comment by Klaus Silveira [ 11/Jul/12 ]

As i said, that hack fixes the problem. But i don't believe that having to change the table name or escape the table name manually is the best solution. Doctrine should be doing that transparently, as it does for other situations (such as during schema creation). Why not during all other operations? Makes no sense at all.

Comment by Marco Pivetta [ 11/Jul/12 ]

This is not a hack... In ORM, "`" is not the MySQL identifier quote. It is exactly thought as a character with which you tell the ORM that the identifier should be quoted.
The default strategy does make use of it, so please use it.

Comment by Marco Pivetta [ 11/Jul/12 ]

Also, we won't collect the SQL reserved keywords, nor we can know what keywords are used in all vendors. The patch for the quoting strategy was exactly thought to allow end users to use insecure names for their objects/fields/indexes/etc but without having the ORM implement those checks for them (since it would just be messy and too "magic").

Please also reconsider your pull request on github too ( DBAL-298 ).

I'm closing this one

Comment by Klaus Silveira [ 11/Jul/12 ]

Then what's the purpose of Doctrine\DBAL\Platforms\Keywords\MySQLKeywords?

Comment by Marco Pivetta [ 11/Jul/12 ]

Klaus Silveira not sure, but it isn't used in ORM.

Comment by Benjamin Eberlei [ 19/Jul/12 ]

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





[DDC-1915] [GH-396] DDC-1893 - Updating configuration to reflect latest Doctrine Common changes Created: 08/Jul/12  Updated: 02/Nov/13  Resolved: 08/Jul/12

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

Type: Bug Priority: Major
Reporter: Benjamin Eberlei Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

Url: https://github.com/doctrine/doctrine2/pull/396

Message:

This PR fixes DDC-1893 (http://www.doctrine-project.org/jira/browse/DDC-1893).

The `getDefaultAnnotationDriver` method was changes to stop supporting older incompatible Doctrine Common versions in favour of the newer logic.

Also, changing logic so that the SimpleAnnotationReader is no more the
default one. An additional parameter for the method will allow using it (this is a BC break!)

The CS fixes that were additionally implemented (along with other minor changes
that do not affect BC compatibility are caused by a CS sniff via IDE.



 Comments   
Comment by Benjamin Eberlei [ 08/Jul/12 ]

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

Comment by Doctrine Bot [ 02/Nov/13 ]

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





[DDC-1900] Impossibility to override built-in SQL functions Created: 30/Jun/12  Updated: 05/Jul/12  Resolved: 05/Jul/12

Status: Closed
Project: Doctrine 2 - ORM
Component/s: DQL
Affects Version/s: Git Master
Fix Version/s: 2.3
Security Level: All

Type: Bug Priority: Major
Reporter: Alex Oroshchuk Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None
Environment:

Any



 Description   

Doctrine doesn't allow to to create own SQL function for DQL if that function is already defined as "built-in". An example could be custom DATE_ADD implementation.
Method FunctionDeclaration() in Doctrine\ORM\Query\Parser gives higher priority to built-in SQL functions, even if they are not
usable for a specific situation, and registering of own datetime function doesn't help. This issue makes it impossible to use some advanced Doctrine extensions,
for example https://github.com/beberlei/DoctrineExtensions that provide fuller implementations.
Considering the fact that someone may want to use ready components provided by the community, and being new to Doctrine can't figure out the way to hack
or workaround this, the issue is a major one.



 Comments   
Comment by Benjamin Eberlei [ 04/Jul/12 ]

Just name the method differently.

Comment by Alex Oroshchuk [ 05/Jul/12 ]

To rename the method one has to KNOW that he has to rename it, i.e. to know about this issue.
One has to SPEND hours (like me) on understanding that there are built-in implementations and other extensions that are meant
to provide necessary features just don't work. IMHO it's just too cruel to leave it as is.

As to the renaming: is it ok to go and edit source code (change class name at least) provided by someone else and then merge all the sources when new releases appear?
Is that the only way flexible Doctrine provides? Also, I want DQL to be as close as possible to real SQL. I don't want to see weird stuff like MY_DATE_ADD or BETTER_DATE_ADD, or whatever it will be.
Syntax matters, we are all writers, code writers...

I re-open the issue in order to attract more attention, but you are free to decide how to treat it. Hope you'll find the best solution. A short line in documentation could notify about current limitations and save hours for people
who want to be productive with Doctrine.

Comment by Benjamin Eberlei [ 05/Jul/12 ]

Printing statements in bold isnt helpful. This is open-source.

However, you are right that this could be more user-friendly. Its now throwing an exception when an internal function is attempted to be overwritten.





[DDC-1843] CLONE -Join columns can't be quoted Created: 28/May/12  Updated: 15/Aug/12  Resolved: 15/Aug/12

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.1.6
Fix Version/s: 2.3
Security Level: All

Type: Bug Priority: Major
Reporter: Marc Easen Assignee: Fabio B. Silva
Resolution: Fixed Votes: 0
Labels: None

Attachments: File quoted_joins_fix.diff    

 Description   

Join columns can't be quoted like columns using name="`quoted`". Using annotation driver.

/**
 * @ORM\Table(
 *      name="`category`",
 *      indexes={
 *          @ORM\Index(
 *              name="fk_category_parentId",
 *              columns={"parentId"}
 *          )
 *      },
 *      uniqueConstraints={
 *          @ORM\UniqueConstraint(
 *              name="uq_category_nameParentId",
 *              columns={"name", "parentId"}
 *          )
 *      }
 * )
 */
class Category
{
    /**
     * @ORM\Id
     * @ORM\Column(type="smallint", name="`id`")
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    protected $id;

    /**
     * @ORM\Column(type="smallint", name="`parentId`", nullable=true)
     */
    protected $parentId;

    /**
     * @ORM\Column(type="string", length=50, name="`name`")
     */
    protected $name;

    /**
     * @ORM\ManyToOne(targetEntity="Category", inversedBy="categories")
     * @ORM\JoinColumn(name="parentId", referencedColumnName="id", onDelete="CASCADE", onUpdate="NO ACTION")
     */
    protected $category;
}

... 


public function load(ObjectManager $manager)
    {
        $parent = new Category();
        $parent->setName('parent');
        $manager->persist($parent);
        $manager->flush();

        $child = new Category();
        $child->setName('parent');
        $child->setParentId($parent->getId());
        $child->setCategory($parent);

        $manager->persist($child);
        $manager->flush();
}

Result: Invalid parameter number: number of bound variables does not match number of tokens



 Comments   
Comment by Fabio B. Silva [ 28/May/12 ]

code format

Comment by Fabio B. Silva [ 25/Jun/12 ]

Fixed by : https://github.com/doctrine/doctrine2/commit/cb72219b118c158c9b5344c4b81ff2b1a9149ab0

Comment by Marc Easen [ 05/Jul/12 ]

When inserting into an entity which has quoted columns and unquoted JoinColumn the generated SQL includes the correct number of parameters but the incorrect columns names and bind parameters:

INSERT INTO `table` (`c1`, c1) VALUES (?, ?)

Comment by Marc Easen [ 05/Jul/12 ]

See https://github.com/doctrine/doctrine2/pull/390

Comment by Fabio B. Silva [ 05/Jul/12 ]

Hi Marc,

Could you attach your entities or a test case please ?

Thanks

Comment by Fabio B. Silva [ 05/Jul/12 ]

Marc, why do you need to quoted columns and unquoted join column ?

For sure duplicated columns is a problem, but your use case does not make sense for me..

Comment by Fabio B. Silva [ 15/Aug/12 ]

More details about the related problem : https://github.com/doctrine/doctrine2/pull/390





[DDC-1591] Paginator: ResultVariable cannot be used in HavingClause Created: 09/Jan/12  Updated: 15/Mar/12  Resolved: 15/Mar/12

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

Type: Bug Priority: Major
Reporter: Christian Raue Assignee: Benjamin Eberlei
Resolution: Fixed Votes: 0
Labels: None


 Description   

Using the QueryBuilder, I'm getting the message

Notice: Undefined index: distance in vendor\doctrine\lib\Doctrine\ORM\Query\SqlWalker.php line 2128

when trying to add a "having" clause for the field "distance", which is defined in the "select" part of the statement:

$queryBuilder
    ->select('myEntity, MY_FUNCTION() AS distance')
    ->having('distance <= 10')
;


 Comments   
Comment by Fabio B. Silva [ 14/Jan/12 ]

Christian, I couldn't reproduce.

Can you give more details ?

Thanks.

Comment by Christian Raue [ 15/Jan/12 ]

I tried it again and found out that it could also be an issue in https://github.com/whiteoctober/Pagerfanta rather in Doctrine itself because my query is passed to that pager to show a sliced result. Maybe that issue could already be resolved by https://github.com/whiteoctober/Pagerfanta/pull/46. Will give it a try...

Comment by Christian Raue [ 15/Jan/12 ]

In fact, applying that patch made the query work. So this is not a Doctrine issue.

Comment by Christian Raue [ 10/Feb/12 ]

Since the PR mentioned was not merged and Doctrine's pagination is used now, the issue still exists and I cannot use a result variable in a "having" clause. But I'd like to.

Comment by Christophe Coevoet [ 10/Feb/12 ]

This ticket is indeed invalid as it is talking about the query builder. Please open a dedicated ticket for the pagination issue

Comment by Christian Raue [ 10/Feb/12 ]

But I am using the QueryBuilder and then passing the query to a DoctrineORMAdapter instance. The error message didn't change, just the line number:

Notice: Undefined index: distance in vendor\doctrine\lib\Doctrine\ORM\Query\SqlWalker.php line 2142

But I can confirm that this error doesn't occur when not using a paginator. How to continue?

Comment by Benjamin Eberlei [ 10/Feb/12 ]

Which paginator are you using?

Comment by Christian Raue [ 10/Feb/12 ]

Still https://github.com/whiteoctober/Pagerfanta/

Comment by Benjamin Eberlei [ 20/Feb/12 ]

Renamed and assigned issue.

Comment by Alexander [ 15/Mar/12 ]

Fixed as sander was kind enough to resubmit the code to the doctrine2 repository now instead:
https://github.com/doctrine/doctrine2/pull/298





[DDC-1931] Cache $oid and $className through method calls in UoW internals Created: 17/Jul/12  Updated: 24/Jul/12  Resolved: 24/Jul/12

Status: Closed
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: None
Fix Version/s: 2.3

Type: Improvement Priority: Minor
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Invalid Votes: 0
Labels: None


 Description   

As suggested by Johannes Schmitt, calls in UoW can re-use $oid and $className by passing them to the various methods of UoW internals



 Comments   
Comment by Marco Pivetta [ 18/Jul/12 ]

Performance gain is nearly 0... Not worth it as far as I've seen.





Generated at Thu Nov 27 13:15:19 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.