[DDC-3803] [GH-1425] Also export default value for fieldMapping Created: 30/Jun/15  Updated: 30/Jun/15

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: Dick Marinus Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Also export default value for fieldMapping.

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

I've added some test cases but on some platforms phpunit failed because composer is out of date.






[DDC-3802] [GH-1443] Unsigned Created: 30/Jun/15  Updated: 30/Jun/15

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 meeuw:

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

Message:

unsigned isn't in $fieldMapping but in $fieldMapping['options']['unsigned']






[DDC-3801] [GH-1442] Corrected bad class reference in "Adding own commands" Created: 30/Jun/15  Updated: 30/Jun/15

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 elazar:

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

Message:






[DDC-3800] [GH-1441] [QUERY] "INSTANCE OF" now behaves correctly with subclasses Created: 29/Jun/15  Updated: 29/Jun/15

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: 1
Labels: None


 Description   

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

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

Message:

There was a bug in the "INSTANCE OF" operator as described in
https://groups.google.com/forum/#!topic/doctrine-user/B8raq8CNMgg

"INSTANCE OF" was not taking into account subclasses.
It was merely translating the class to its discriminator.
This is not correct since the class can have subtypes and those
are, indeed, still instance of the superclass.
Also, classes may not have a discriminator (e.g. abstract classes).

This commit also provide useful tests to avoid regression.






[DDC-3799] Unexpected outcome when using prePersist event and ID GeneratedValue strategy is set to NONE Created: 29/Jun/15  Updated: 29/Jun/15

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

Type: Documentation Priority: Minor
Reporter: yanick Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Setup: I have an entity that uses natural ids (GeneratedValue strategy is set to none). The entity also has life cycle callbacks for prePersist and preUpdate.

Expectation: The UnitOfWork would throw an EntityNotFoundException if I attempt to merge an untracked entity that does not exist in the database. I can catch the exception and call persist. All life cycle callbacks would be executed.

Outcome: No exception is thrown. The UOW creates a new instance of the the incoming object using only the ID. Persist is called on the newly created object and prePersist executes against the empty object. Finally the incoming entity is merged, which overwrites any properties that are managed by prePersist.

I was able to work around this by setting the GeneratedValue strategy to "Custom" and CustomIDGenerator to the AssignedGenerator.






[DDC-3798] Allow Collections to be used transparently with Array-Types Created: 29/Jun/15  Updated: 29/Jun/15

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

Type: Improvement Priority: Minor
Reporter: Robert Schönthal Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Currently its not possible to use Collection with Array-Types transparently:

Entity.php
Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
class Entity
{
    /**
     * @var string[]|Collection
     *
     * @ORM\Column(type="json_array")
     */
    private $aliases = [];

    public function __construct()
    {
        $this->aliases  = new ArrayCollection();
    }
}

if i add Values to the Collection and persist the Entity the aliases are empty.
I need Lifecycle Listener which converts between ArrayCollection and array like this:

Entity.php
Unable to find source-code formatter for language: php. Available languages are: actionscript, html, java, javascript, none, sql, xhtml, xml
    /**
     * @ORM\PrePersist
     */
    public function prePersist()
    {
        $this->aliases = $this->aliases->toArray();
    }

it would be good to have an automatic conversion! Should be fairly easy, i could write a PR if your interessted in...or am i missing a hidden piece?






[DDC-3797] IDENTITY function does not hydrate custom types Created: 26/Jun/15  Updated: 26/Jun/15

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: Marcos Passos Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

The function IDENTITY does not hydrate customs types. I've a OrganizationId type, but when a execute the following DQL I got an error, because Doctrine tries to pass an integer as argument of my object constructor instead of an OrganizationId instance.

<mapped-superclass name="Campaign">
        <id name="id" column="id" type="campaign_id" />
        <id name="organization" column="organization_id" association-key="true" />
        <many-to-one field="organization" target-entity="Organization">
            <join-column name="organization_id" referenced-column-name="id" on-delete="CASCADE" on-update="CASCADE" />
        </many-to-one>
    </mapped-superclass>
SELECT NEW CampaignDTO(c.id, IDENTITY(c.organization), c.name) FROM Campaign c

Result:

Catchable Fatal Error: Argument 2 passed to Campaign::__construct() must be an instance of OrganizationId, integer given





[DDC-3796] SELECT NEW does not work with composite keys Created: 26/Jun/15  Updated: 26/Jun/15

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: Marcos Passos Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

I'm getting an error trying to instantiate a DTO using a column that is used as ID and foreign key.

<mapped-superclass name="Campaign">
        <id name="id" column="id" type="campaign_id" />
        <id name="organization" column="organization_id" association-key="true" />
        <field name="name" column="name" type="string" length="255" />
        <many-to-one field="organization" target-entity="Organization">
            <join-column name="organization_id" referenced-column-name="id" on-delete="CASCADE" on-update="CASCADE" />
        </many-to-one>
    </mapped-superclass>
SELECT NEW CampaignDTO(c.id, c.organization, c.name) FROM Campaign c

Result:

[Semantical Error] line 0, col 54 near 'organization,': Error: Invalid PathExpression. Must be a StateFieldPathExpression.





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

Status: Awaiting Feedback
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.4.1, 2.6.0
Fix Version/s: None

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

Attachments: File DDC2838Test.php    
Issue Links:
Reference
is referenced by DCOM-275 Collections\Expr\ClosureExpressionVis... Open
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.

Comment by Florian Preusner [ 26/Dec/14 ]

+1

Comment by Simon Paridon [ 26/Jun/15 ]

My idea to solve this would go like this:

  • Add a new class ObjectCollection in Common that implements Collection and Selectable, but requires class metadata.
  • Whenever creating an ArrayCollection with entities / other objects, create an ObjectCollection instead.

The only thing that's causing me a headache is that ideally, there should be code sharing in some form between the matching() implementations of ObjectCollection and PersistentCollection, because both will use class metadata. Maybe this can be achieved somehow using a trait?

If you like the idea, I could look into it further.





[DDC-3795] [GH-1439] One to one unique index mapping bug Created: 26/Jun/15  Updated: 26/Jun/15

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 baerrach:

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

Message:

As per request on google groups.

My original problem was that schema:validate is telling me the database is not up to date and the only SQL it wants to run is DROP INDEX and CREATE INDEX on what is already there.

To write some tests to see why, I started hacking OrmFunctionalTestCase to give me back the class metadata for the model set in use. And while I was doing that I DRYed up the test setup to avoid duplication. But the ValueConversionType stopped working because they DROP TABLES when no other tests do. I think the drop tables was necessary because they use the same entities across some of the different test classes so when the entites were setup the would fail because the table already existed - which is the problem I bumped into.

I've got the code working by sharing the schema creation setup and not dropping tables, but because of this OneToOne mapping issue the tests fail because the unique index name already exists in the name space.

I've pushed the code changes to https://github.com/baerrach/doctrine2/tree/one-to-one-unique-index-mapping-bug so you can see what I am talking about.

Its done in three stages:

b0ce47d Remove tearDownAfterClass() and DROP TABLES

4b5cd37 DRY test setup for entities and modelSets

f7efac6 Fix OneToOne unique constraint mapping

You can run the ValueConversionType to see the failures, and resolution, in action.

phpunit -d memory_limit=-1 tests/Doctrine/Tests/ORM/Functional/ValueConversionType/






[DDC-3794] Cannot set default value on a @joinColumn Created: 25/Jun/15  Updated: 25/Jun/15

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

Type: Bug Priority: Major
Reporter: Ben Meynell Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: joins, schema, schemadiff, validator
Environment:

Symfony 2.3; Ubuntu 14.04



 Description   

The @Column allows for options={"default":1}).

However, @joinColumn does not support options={"default":1}).

The implication of this is that a default value can never be set for new database schemas and for existing schemas that have DEFAULT '1' included in its column definition a schema mismatch will occur when running doctrine:schema:validate.

Since there is no way to define a default on the entity-level there is no way to reconcile the mismatch. Instead, the default value just be removed from the database schema and be enforced on the application level.






[DDC-3720] Doctrine - Invalid column name 'sclr0' Created: 29/Apr/15  Updated: 25/Jun/15

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

Type: Task Priority: Major
Reporter: Belita Colares Assignee: Guilherme Blanco
Resolution: Unresolved Votes: 0
Labels: querybuilder


 Description   

My query doesn't work when i use ->setMaxResult with orderBy SUM.

My dataBase is MSSQL SERVER 2008 R2

$query = $entity->createQueryBuilder('t')
                        ->select('SUM(t.price) AS test')
                        ->setMaxResults(10)
 ->orderBy('test', 'ASC')->getQuery()->getResult();

when i use only
'->select('t.price AS test') ->setMaxResults(10) ->orderBy('test', 'ASC');' doesn't work too

Invalid column name 'sclr0'.
but when i comment this method setMaxResult() my query works fine.

Please help-me, I sorry my english.






[DDC-3793] Unit Of Work - Proxy injected collections 'PersistentCollections' Created: 24/Jun/15  Updated: 24/Jun/15  Resolved: 24/Jun/15

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

Type: Improvement Priority: Major
Reporter: Leonel Franchelli Assignee: Marco Pivetta
Resolution: Duplicate Votes: 0
Labels: PersistentCollection, UnitOfWork
Environment:

Symfony 2.7 , Doctrine 2.5.0


Attachments: PNG File Selection_008.png     PNG File Selection_009.png     PNG File Selection_010.png    
Issue Links:
Duplicate
duplicates DDC-391 Allow to specifiy custom Entity and C... In Progress
duplicates DDC-80 Allow custom collections Resolved

 Description   

Hi all , i was looking to extend ArrayCollection i did it, but i notice something very very unusual, when an entity is loaded from the DB the unit of work most precisely on the method 'createEntity' it injects PersistentCollection object in the collections of all the entities, why you do that ?

Is there any way to inject my own subclass of PersistentCollection to the proxy objects ? Of course i know that i have to also extend PersistentCollection and create a CustomPersistentCollection

Sry for my english



 Comments   
Comment by Marco Pivetta [ 24/Jun/15 ]

Custom persistent collections are not yet supported.

See DDC-80 and DDC-391

Comment by Leonel Franchelli [ 24/Jun/15 ]

Thx for answering so quickly , well i just hope in some future version you add this feature eventually





[DDC-80] Allow custom collections Created: 30/Oct/09  Updated: 24/Jun/15  Resolved: 02/Jan/11

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

Type: Improvement Priority: Minor
Reporter: Ville Väänänen Assignee: Roman S. Borschel
Resolution: Won't Fix Votes: 1
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3793 Unit Of Work - Proxy injected collect... Resolved
Reference
relates to DDC-546 New fetch mode EXTRA_LAZY for collect... Resolved

 Description   

There should be a configuration option which specifies the class-name of the collection that will be created. The specified collection should implement the \Doctrine\Common\Collections\Collection interface. A custom collection would be needed if one want's to have some sort of aggregate functions, like 'getSum()' or 'getWeight()' for example.



 Comments   
Comment by Roman S. Borschel [ 30/Oct/09 ]

You can already use any Collection implementation you like as long as you program to the interface after the entity has become managed (or detached). This is from the manual:

"Collection-valued persistent fields and properties must be defined in terms of the Doctrine\Common\Collections\Collection interface. The collection implementation type may be used by the application to initialize fields or properties before the entity is made persistent. Once the entity becomes managed (or detached), subsequent access must be through the interface type."

The only thing that could probably be enhanced is to instantiate custom collection types when reconstituting entities from the database. But remember, even then you must program to the interface, not the concrete implementation, therefore, what you have in mind might not work. Collection implementations are wrapped in a PersistentCollection during runtime for change-tracking/lazy-load. A PersistentCollection supports the Collection interface only.

I have thought about implementing __call in PersistentCollection to forward unknown method calls to the wrapped instance. However I'm not sure I like that. Doctrine would be unaware of any changes that are made to the collection in those methods, making them rather fragile.

I hope you get the picture

Comment by Christian Heinrich [ 07/May/10 ]

I'm currently browsing through some open tickets and I think we could mark this one as invalid / won't fix, as the wrapping is a major feature.

Comment by Benjamin Eberlei [ 01/Jul/10 ]

I think this two go hand in hand, if we do the EXTRA_LAZY stuff we could also do this one here.

Comment by Benjamin Eberlei [ 01/Jul/10 ]

Ok, slightly modified, you can specifiy which persistent collection implementation you want to use for your entities.

Comment by Benjamin Eberlei [ 02/Jan/11 ]

This is not necessary anymore with EXTRA_LAZY collections, closing. Allowing to specifiy own collections wouldn't help since most often you also need to touch other parts (UnitOfWork Persisters) so its better for code-maintenance to just not allow this.





[DDC-391] Allow to specifiy custom Entity and Collection Persister classes Created: 06/Mar/10  Updated: 24/Jun/15

Status: In Progress
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.0-ALPHA4
Fix Version/s: 2.x
Security Level: All

Type: New Feature Priority: Minor
Reporter: Benjamin Eberlei Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 9
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-3793 Unit Of Work - Proxy injected collect... Resolved
Reference
is referenced by DDC-2637 [GH-769] Add Custom Persisters Open
is referenced by DDC-699 ProxyFactory: allow to overwrite $_pr... Resolved
is referenced by DDC-445 Evaluate possible ways in which store... Resolved

 Description   

It should be allowed to overwrite the default persisters for collections and entities. This should go along the lines of Hibernate which allows to set the custom implementations like:

XML:

<entity persister="persisterClass" />
<OneToMany persister="persisterClass" />

Annotation

/**
 * @Entity(persister="persisterClass")
 * @OneToMany(persister="persisterClass")
 */


 Comments   
Comment by Roman S. Borschel [ 19/May/10 ]

Rescheduling for beta3.

Comment by Roman S. Borschel [ 07/Jul/10 ]

Pushing back to beta4.

Comment by Roman S. Borschel [ 12/Jul/10 ]

Moved to 2.1 due to lack of time for any larger new features for 2.0.

Comment by Benjamin Eberlei [ 13/Oct/10 ]

implemented this in a feature branch for now, it really doesnt touch any other runtime code so maybe we can still merge this before RC1

http://github.com/doctrine/doctrine2/tree/OverridePersisters

Comment by Gediminas Morkevicius [ 25/Feb/11 ]

Is this forgotten? you should merge it since it does not affect any other parts of ORM, this is a great feature

Comment by Benjamin Eberlei [ 26/Feb/11 ]

This has not been forgotten, but the Persister is due for a heavy refactoring for 2.2 probably, when we will make it use the SQL Query object that we are working on.

So I cannot merge this, because the API will probably break big time.

Comment by Jonas Wouters [ 16/Mar/11 ]

Does that mean we will not see this feature before 2.2?

Comment by Benjamin Eberlei [ 16/Mar/11 ]

Yes, that is correct. I dont want to add it as experimental/undocumented feature because people will take it for granted and make us responsible for possible bc breaks.

I will update the target version accordingly.

Sorry for disappointing you, but this feature is fundamentally important at the core of the library. That means we have to get it right and not rush into it.

Comment by Gediminas Morkevicius [ 17/Mar/11 ]

Just as I thought that first you will want to make a query builder object for all persisters. since now they use plain sql. Thanks for all your work on this

Comment by Adam Brodziak [ 11/Jan/12 ]

I might be mistaken, but AFAICS mentioned Persister heavy refactoring did not made through to 2.2 version. Is there any plan to have it in 2.3 or at any later stage?

Comment by Guilherme Blanco [ 13/Jan/12 ]

@Adam I refactored all Persisters optimizing their code, but I could not complete the move from SQL string generation to Doctrine\DBAL\Query.
We missed it, yes. I may reschedule for 2.3

Comment by Thomas Rothe [ 05/Sep/12 ]

Why is it still missing in 2.3? I would require this for an extension that uses its own overridden entity persister and using a custom persister is the solution that you guys recomend for not overriding the entity manager.

Comment by sebastiaan stok [ 23/Sep/12 ]

Any change seeing this soon? I really need this for a security feature.

What is making this so hard? just adding an setEntityPersister($entityName, $object) should do the trick.
I don't need any fancy stuff, just a way to limit the fields in the SELECT list.

Edit: OK, I'm shot I CAN NOT overwrite the entity manager as the UnitOfWork is private!
Got any other idea?

Comment by Stefan Kögel [ 24/Sep/12 ]

Any chance you could add this quickly? I need this feature urgently to complete an extension using a custom persister. Thanks in advance.

Comment by Lennart Weijl [ 09/Jul/13 ]

What's the status on this issue?





[DDC-445] Evaluate possible ways in which stored procedures can be used Created: 19/Mar/10  Updated: 24/Jun/15  Resolved: 24/Jun/15

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

Type: Improvement Priority: Minor
Reporter: Roman S. Borschel Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 1
Labels: None

Issue Links:
Reference
relates to DDC-391 Allow to specifiy custom Entity and C... In Progress

 Description   

We should evaluate the current situation of stored procedure support as well as where we want to go with it / how far we want to support it, if at all.



 Comments   
Comment by Benjamin Eberlei [ 19/Mar/10 ]

I think this relates to the usage of Custom Persisters

Comment by Marco Pivetta [ 24/Jun/15 ]

Stored procedures are absolutely a no-go in terms of interop. Closing as won't fix.





Generated at Wed Jul 01 16:57:07 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.