[DDC-3451] [GH-1221] Very simple refactoring of the setup class Created: 16/Dec/14  Updated: 17/Dec/14  Resolved: 17/Dec/14

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

Type: Improvement Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

Moved logic to instance methods.

This way, a project could depend on a Setup class instance (or extend it) and resolve it through a DI container.
To allow for BC, instance methods were renamed and a `__callStatic` magic method deals with finding them.
Tests were duplicated to test for static access and instance access.



 Comments   
Comment by Doctrine Bot [ 16/Dec/14 ]

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

Comment by Doctrine Bot [ 17/Dec/14 ]

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





[DDC-3454] [GH-1224] Updated setParameters function for not replace all parameters Created: 17/Dec/14  Updated: 17/Dec/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: 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 uthopiko:

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

Message:

When you create QueryBuilder and you bind some parameters, if you use setParameters function after bind other parameters, previous parameters are removed(https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/QueryBuilder.php#L558). This would not be a problem if it was the same behaviour with the attribute $_parameterMappings (in ParserResult), but it's not the case, given that it keeps the number of parameters introduced, throwing an exception(https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Query.php#L293). To prevent this, I've made it initialize the setParameters with the existing ones.



 Comments   
Comment by Doctrine Bot [ 17/Dec/14 ]

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





[DDC-2838] Leaky abstraction when applying Criteria to hydrated/non-hydrated PersistentCollection Created: 03/Dec/13  Updated: 17/Dec/14

Status: Reopened
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.1
Fix Version/s: None

Type: Bug Priority: Major
Reporter: brian ridley Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: None

Attachments: File DDC2838Test.php    
Issue Links:
Reference
is referenced by DCOM-249 Criteria are unable to locate getters... Open

 Description   

When applying a Criteria to a PersistentCollection that has been hydrated the field names must be camel case, if the collection has not yet been hydrated the field names must be underscore separated.

The github repo linked here contains a simplified testcase for the matrix of hydrated/non-hydrated entities and camel case/underscore separated fields.

https://github.com/ptlis/DoctrineTestcase



 Comments   
Comment by Marco Pivetta [ 18/Aug/14 ]

We can't check out an entire project just to test a bug.

Please write an actual functional test case that can be integrated into the Doctrine ORM test suite.

Comment by brian ridley [ 20/Aug/14 ]

Hi,

i'm happy to do so - i'll take a look at this over the weekend.

Comment by Simon Paridon [ 12/Dec/14 ]

brian ridley: Any progress on this? This is currently an issue for us as well and hope to get fixed. I could look into converting it to a test for integration with the test suite if you don't have the time... but it might take a while since I have no experience with the requirements that should be met. (Plus, I am not sure how tightly coupled it is with your project)

Comment by Simon Paridon [ 17/Dec/14 ]

Hi Marco Pivetta, brian ridley,

I attached a functional Test that integrates with the test suite. Please let me know if I should issue a PR, and I'll do that this evening.





[DDC-3453] [GH-1223] Refactored construction of the EntityManager out to an EntityManagerFactory Created: 17/Dec/14  Updated: 17/Dec/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: 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 guiwoda:

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

Message:

Added tests for the factory (needed to refactor the OrmTestCase so I could reuse mock config and mock connections).

This pattern is well established in Hibernate, I've been wondering why we don't have it in Doctrine.






[DDC-3452] [GH-1222] Embeddables in metadata builder Created: 17/Dec/14  Updated: 17/Dec/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: 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 guiwoda:

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

Message:

Embeddables set the `$classMetadata->isEmbeddedClass = true` and sets `$classMetadata->isMappedSuperclass = false`, imitating the `switch` in xml / yml drivers.

Embeddeds have 2 methods, as other types have: `addEmbedded` is a one-off adder with fluent behavior, and `createEmbedded` returns an instance of `EmbeddedBuilder`. The class is very thin right now, but it's a good way to lay ground for improvements on embedded creation in the future.

This one is probably more useful than the last one, @Ocramius






[DDC-3450] Embeddables containing only nested embeddables are not hydrated properly Created: 16/Dec/14  Updated: 16/Dec/14

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

Type: Bug Priority: Major
Reporter: James Moss Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have the following object mapping:

Location (entity)

  • name <string>
  • bounds <Bounds>

Bounds (embeddable)

  • northeast <Coords>
  • southwest <Coords>

Coords (embeddable)

  • latitude <float>
  • longitude <float>

This setup works fine when persisting entities, the database schema is correct, etc. but when I fetch my `Location` entity afterwards the `bounds` property is wrong. It looks something like this. Calling `getBounds()` on `Location` returns something like:

Coords

  • latitude <float>
  • longitude <float>
  • northeast <Coords>
  • southwest <Coords>

As if the `Coords` embeddable has been transposed with the `Bounds` embeddable.

If I add another property to `Bounds` that isn't an embeddable (say a string) then it's hydrated correctly.



 Comments   
Comment by Marco Pivetta [ 16/Dec/14 ]

James Moss could you come up with a small test case in https://github.com/doctrine/doctrine2/tree/v2.4.7/tests/Doctrine/Tests/ORM/Functional/Ticket ?





[DDC-2589] [GH-746] Makes children of AbstractQuery non-final. Created: 05/Aug/13  Updated: 16/Dec/14  Resolved: 06/Aug/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 0
Labels: None


 Description   

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

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

Message:

b66d530540d18c60720e1843fc65ce7e0399a71c made these classes final, but there is no rationale for this change given in the commit log. Leaving this as final makes it impossible to mock and makes testing some areas of code difficult (or impossible).



 Comments   
Comment by Doctrine Bot [ 05/Aug/13 ]

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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





[DDC-2587] [GH-744] Corrected PHP type for "decimal" mapping type Created: 03/Aug/13  Updated: 16/Dec/14  Resolved: 10/Aug/13

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

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


 Description   

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

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

Message:

"Basic Mapping" documentation says:
"decimal: Type that maps a SQL DECIMAL to a PHP string."



 Comments   
Comment by Doctrine Bot [ 10/Aug/13 ]

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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

Comment by Doctrine Bot [ 16/Dec/14 ]

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





[DDC-3449] Single scalar Result and Hidden field Created: 15/Dec/14  Updated: 15/Dec/14

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

Type: Bug Priority: Minor
Reporter: Thomas Gallice Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I have try to get a single scalar result but my query contains a HIDDEN field. The result is the `NonUniqueResultException` exception.






[DDC-3448] @OrderBy on eager @OneToMany does not work Created: 13/Dec/14  Updated: 13/Dec/14

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

Type: Bug Priority: Major
Reporter: Oliver Hoff Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

generated code when eagerly fetching:

SELECT 
  t0.id AS id_8,
  t19.category_id AS category_id_23 
FROM 
  category t0 
  LEFT JOIN attribute_category t19 ON t19.category_id = t0.id 
WHERE 
  t0.id = ?

when fetching lazy the collection query has the ORDER BY clause






[DDC-2583] [GH-742] Cleaned up events.rst Created: 30/Jul/13  Updated: 13/Dec/14  Resolved: 25/Aug/13

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Was a mix-up between TestEventSubscriber and EventTest (e.g. the definition of TestEventSubscriber referenced TestEvent::preFoo, which did not exist). To clarify this I've renamed EventTest to TestEvent.

Tried to clarify the text in the Naming Convention section.

Added note that onClear is not a lifecycle callback.

Tried to clarify the definition of Lifecycle Callbacks.

Separated key/value descriptions into XML and YAML parts since the details are different

Added note in Implementing Event Listeners section that since 2.4 you do have access to EntityManager and UnitOfWork from lifecycle callbacks.

Added example about how to use the computed changeset to modify a primitive value in preUpdate section

Added naming convention example to Entity listeners class section

The other changes are typos and small fixes.



 Comments   
Comment by Doctrine Bot [ 25/Aug/13 ]

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

Comment by Marco Pivetta [ 25/Aug/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/e2a67c2f1c1f2f7e670264c52294968963f3b242

Comment by Doctrine Bot [ 13/Dec/14 ]

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





[DDC-2568] [GH-733] Update Parser.php Created: 24/Jul/13  Updated: 12/Dec/14  Resolved: 24/Jul/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Fix the docummentation for Parser::Literal()



 Comments   
Comment by Doctrine Bot [ 24/Jul/13 ]

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

Comment by Marco Pivetta [ 24/Jul/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/d7881a1ec2173e4b83c2222094cfeef64c474772

Comment by Doctrine Bot [ 10/Dec/14 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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





[DDC-2562] [GH-730] To avoid "SpacingAfterParams" error with PHPCS Symfony2 coding standard Created: 22/Jul/13  Updated: 12/Dec/14  Resolved: 22/Jul/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:

Hello,
I added two blank lines in comments two avoid the following error with PHPCS Symfony2 coding standard :
Error Code: SpacingAfterParams
Error Description: Last parameter comment requires a blank new line after it.



 Comments   
Comment by Doctrine Bot [ 22/Jul/13 ]

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

Comment by Marco Pivetta [ 22/Jul/13 ]

Merged at https://github.com/doctrine/doctrine2/commit/8d2826c6334c705886d84768eb139b6be83bf386

Comment by Doctrine Bot [ 29/Nov/14 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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





[DDC-2582] [GH-741] Fixed DDC-1884. Created: 30/Jul/13  Updated: 12/Dec/14  Resolved: 08/Aug/13

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

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


 Description   

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

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

Message:

Fixed original failing test case provided in https://github.com/doctrine/doctrine2/pull/395 and highlighted as an issue in http://www.doctrine-project.org/jira/browse/DDC-1884



 Comments   
Comment by Doctrine Bot [ 30/Jul/13 ]

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

Comment by Doctrine Bot [ 30/Jul/13 ]

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

Comment by Fabio B. Silva [ 08/Aug/13 ]

Merged, For more details see : https://github.com/doctrine/doctrine2/pull/741

Comment by Doctrine Bot [ 18/Dec/13 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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

Comment by Doctrine Bot [ 12/Dec/14 ]

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





[DDC-3443] Doctrine Custom Type always converted as string, when not wanted Created: 09/Dec/14  Updated: 12/Dec/14

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

Type: Bug Priority: Major
Reporter: Romain Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dql, postgresql
Environment:

Symfony2, PDO_PostgreSQL



 Description   

Hello,

trying to define a Custom Type in my Symfony2 application, I can't find how to write the convertToDatabaseValue function for working with native points in PostgreSQL (!= PostGIS extension).

Wished syntax :

'SELECT [...] FROM Addresses t0 WHERE t0.location = ?' with params ['(2.352,48.857)']

I use this convertToDatabaseValue function :

    public function convertToDatabaseValue($value, AbstractPlatform $platform) {
        if (!$value) return;

        return "'(".$value->getX().','.$value->getY().")'";
    }

DQL, creates this SQL query :

'SELECT [...] FROM Addresses t0 WHERE t0.location = ?' with params ["'(2.352,48.857)'"]

-> Double quotes are automatically added, the parameter is interpreted as string.

I don't know if it is a bug or if I am doing anything wrong ?

Thank you.



 Comments   
Comment by Marco Pivetta [ 10/Dec/14 ]

Please check http://doctrine-orm.readthedocs.org/en/latest/cookbook/advanced-field-value-conversion-using-custom-mapping-types.html and compare it with your codebase.

Comment by Romain [ 10/Dec/14 ]

As I understand, the function convertToDatabaseValue build the format from the value into "with params (############)"

But it does always put double quotes so that my value becomes a string.

convertToDatabaseValueSQL build the format before, at the placeholder and here, I don't want to change anything.

I tried also

getBindingType()

{ return \PDO::PARAM_NULL; }

Hoping that were going to remove the quotes, but it doesn't.

Any suggestion ?

Comment by Steve Müller [ 12/Dec/14 ]

Not sure but I think the double quotes are just added for the debug output. What would be the native SQL that you expect?
I think you will have to define \PDO::PARAM_STRING as binding type and remove the single quotes around your database value:

public function convertToDatabaseValue($value, AbstractPlatform $platform) {
    if (!$value) return;

    return "(".$value->getX().','.$value->getY().")";
}




[DDC-3284] Yaml mapping. Comment on table and realtion Created: 29/Aug/14  Updated: 12/Dec/14

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

Type: Documentation Priority: Major
Reporter: Vladimir Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: None
Environment:

Windows, XAMPP, PHP5.3, ZF2, Doctrine-ORM



 Description   

Is there any way to comment my tables and table relations with yml schema?
I can comment plain field like this

        prediction:
            type: text
            nullable: true
            length: null
            fixed: false
            options:                
                comment: 'program prediction'

But for relation:

        project:
            targetEntity: File\Entity\File
            cascade: {  }
            mappedBy: null
            inversedBy: null
            joinColumns:
                project:
                    referencedColumnName: id
            orphanRemoval: false
            options:                
                comment: 'File with project data'

Or for whole table:

Program\Entity\Program:
    type: entity
    table: program
    options:
        comment: 'State program table'

It doesn't work at all. When I perform migrations those comments are totally ignored. And I can't find any documentation for yml mapping table commenting



 Comments   
Comment by Steve Müller [ 29/Aug/14 ]

Commenting tables is a vendor specific feature and therefore not all database vendors support it. I think currently it is only possible to comment tables via mapping for MySQL. The mapping you provided for commenting tables should work however. See here: https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Mapping/Driver/YamlDriver.php#L247-L249
I'm not quite sure what you mean by commenting relations. Where would you expect Doctrine to add a comment to?

Comment by Vladimir [ 29/Aug/14 ]

I mean commenting a column that is a foreign key. Like 'project' column above that is a link to Files table and entity.

Comment by Steve Müller [ 01/Sep/14 ]

Unfortunately commenting columns part of an association mapping is not possible in ORM at the moment.

Comment by Martijn Zijlstra [ 09/Dec/14 ]

I tried doing this with annotations by adding a column annotation to the relation, but this effectively removed the relation alltogether. So no workaround yet.

Comment by Steve Müller [ 12/Dec/14 ]

Commenting foreign key columns is simply not supported yet via ORM mapping.





[DDC-2581] [GH-740] Synchronized support of FilterCollection with ODM by adding missing method Created: 30/Jul/13  Updated: 11/Dec/14  Resolved: 30/Jul/13

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

Type: Bug Priority: Major
Reporter: Doctrine Bot Assignee: Guilherme Blanco
Resolution: Fixed Votes: 0
Labels: None


 Description   

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

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

Message:



 Comments   
Comment by Doctrine Bot [ 30/Jul/13 ]

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

Comment by Marco Pivetta [ 30/Jul/13 ]

Merged: https://github.com/doctrine/doctrine2/commit/0e010994a7588de868dc57b49d081a8a9a6e9b1d

Comment by Doctrine Bot [ 11/Dec/14 ]

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

Comment by Doctrine Bot [ 11/Dec/14 ]

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





[DDC-3441] Unidirectional ManyToOne Not Lazy Loading Created: 09/Dec/14  Updated: 11/Dec/14

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

Type: Bug Priority: Critical
Reporter: Marcus Fulbright Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: lazy-loading, proxy, public-properties, reflection

Issue Links:
Dependency
depends on DDC-3442 [GH-1217] @DDC3441 failing test cases... Open

 Description   

The Unidirectional ManyToOne association described in the docs does not lazy load correctly. The appropriate SQL will get executed, and the returned Proxy does pass type hinting for the correct class. However, the lazy loaded object always has the following properties:

  • _initializer_
  • _cloner_
  • _isInitialized_
  • lazyPropertiesDefaults

Any properties from the class definition do not show up. This is problematic when trying to get reflected properties and their values. Methods are correctly reflected.

Pull request for failing test case



 Comments   
Comment by Marcus Fulbright [ 09/Dec/14 ]

Let me know if anything else is needed.

Comment by Doctrine Bot [ 11/Dec/14 ]

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

Comment by Marco Pivetta [ 11/Dec/14 ]

Looks like a current ORM limitation (private properties lazy loading).

Related:





[DDC-3442] [GH-1217] @DDC3441 failing test cases for the ticket Created: 09/Dec/14  Updated: 11/Dec/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: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None

Issue Links:
Dependency
is required for DDC-3441 Unidirectional ManyToOne Not Lazy Loa... Open

 Description   

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

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

Message:

Failing test cases for the ticket DDC-3441(http://www.doctrine-project.org/jira/browse/DDC-3441)



 Comments   
Comment by Marcus Fulbright [ 09/Dec/14 ]

I didn't realize a ticket would get automatically opened when I submitted a pull request. I already put relevant details for this in DDC-3441. This is a duplicate.

Comment by Doctrine Bot [ 11/Dec/14 ]

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





Generated at Thu Dec 18 14:34:53 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.