[DDC-3852] [GH-1479] Quoted field - yaml driver Created: 28/Jul/15  Updated: 28/Jul/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 bigfoot90:

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

Message:

Allow the usage of ```quoted``` field mapping option in yaml mappings

Example:
```
MyModel:
type: entity
fields:
values:
type: string
quoted: true
```






[DDC-3730] Embeddable hydrates to object instead of null Created: 08/May/15  Updated: 28/Jul/15

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

Type: Bug Priority: Major
Reporter: Paul Cioanca Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: None


 Description   

Good afternoon,

When hydrating an Embeddable with nullable attributes the result is an instance of the Embeddable class , this is obviously correct and expected behavior.

If all the attributes are null the hydrator will still return an instance of the class with all of its properties null , even if I persist and flush my Entity with the Embeddable being set as null .

For clarification :


class MyEntity
{
    protected $myEmbeddable;

    public function setMyEmbeddable(MyEmbeddable $myEmbeddable = null)
    {
        $this->myEmbeddable = $myEmbeddable;
    }
    [...]
}

$newEntity = new MyEntity();
$newEntity->setMyEmbeddable(null);

$em->persist($newEntity);
$em->flsuh($newEntity);

Calling $newEntity->getMyEmbeddable() will return an instance of the MyEmbeddable object with all of it's attributes set to null .

I expected $newEntity->getMyEmbeddable() to be NULL .

Can someone clarify is this is expected behaviour ? In case it is , how can I achieve what I'm looking for ?

Best regards



 Comments   
Comment by Eugene Dounar [ 28/Jul/15 ]

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





[DDC-3834] [GH-1465] Spl_object_hash conflict on Merge Created: 16/Jul/15  Updated: 28/Jul/15

Status: Awaiting Feedback
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 moroine:

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

Message:

This is proper PR which was originally https://github.com/doctrine/doctrine2/pull/1461(https://github.com/doctrine/doctrine2/pull/1461)

Hi,

First of all, this is just a proposal and I'm sure there is a better solution for the problem described here. As this is my first hack into doctrine source code I'm not sure consequences that might be cause by my modification (even all unit tests passes).

I have encounter a problem due to spl_object_hash. I have written a functional test in order to reveal my issue.

The problem is when I merge an entity, here $user, UOW keep data on the original entity identified by it's spl_object_hash. Then if I unset this $user the spl_object_hash is now available for new object. So I experimented in my case reuse of previous hash which cause a managed+dirty entity error.

So I see two solutions

UOW keep reference to the entity given as even the given variable is unset there is remaining reference in UOW so the spl_hash will not be released.
Do not store data about the given entity, as merge operation isn't supposed to modified given entity.
I tried to implement the second solution as the first may consume a much more memory.

I don't why the merge operation need to do this, so I encapsulated it to prevent unwanted bug






[DDC-3851] [GH-1478] attributeOverride on mappedSpuerclass YamlDriver Created: 27/Jul/15  Updated: 27/Jul/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 bigfoot90:

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

Message:

This allows the use of ```attributeOverride``` on a mappedSpuerclass yaml format.
Without this you have exception
```[Doctrine\ORM\Mapping\MappingException] Invalid field override named 'field' for class 'Acme\DemoBundle\Entity\Custom'```

replace of https://github.com/doctrine/doctrine2/pull/1477 beacause of wrong branch.






[DDC-3850] [GH-1477] attributeOverride on mappedSpuerclass YamlDriver Created: 27/Jul/15  Updated: 27/Jul/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 bigfoot90:

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

Message:

This allows the use of ```attributeOverride``` on a mappedSpuerclass yaml format.
Without this you have exception
```[Doctrine\ORM\Mapping\MappingException] Invalid field override named 'field' for class 'Acme\DemoBundle\Entity\Custom'```



 Comments   
Comment by Doctrine Bot [ 27/Jul/15 ]

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





[DDC-3106] [GH-1023] [DDC-3027] Avoid duplicated mapping using Embedded in MappedSuperclass Created: 30/Apr/14  Updated: 27/Jul/15  Resolved: 15/May/14

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

Type: Bug Priority: Trivial
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 coma:

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

Message:



 Comments   
Comment by Doctrine Bot [ 30/Apr/14 ]

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

Comment by Doctrine Bot [ 15/May/14 ]

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

Comment by Damian Dlugosz [ 27/Jul/15 ]

I've commented the line ```if (!$class->isMappedSuperclass) {```
https://github.com/doctrine/doctrine2/pull/1023/files#diff-ecaa162f62bde19c758286c766911141R144
and tests are good anyway, is this line really necessary?





[DDC-3825] simple_array slush with empty array Created: 14/Jul/15  Updated: 27/Jul/15

Status: Open
Project: Doctrine 2 - ORM
Component/s: ORM
Affects Version/s: 2.3, 2.4, 2.5
Fix Version/s: 2.3, 2.4, 2.5

Type: Bug Priority: Minor
Reporter: Damian Dlugosz Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: dbal


 Description   

I'm using "doctrine/orm": v2.5.0 and have simple_array type.
If I persist the class where the property with type simple_array is empty array() the query fails.

I'm coming with solution, please see the github PR https://github.com/doctrine/dbal/pull/877



 Comments   
Comment by Damian Dlugosz [ 27/Jul/15 ]

I've mapped the field as nullable=false, so it should never be null.
If you cannot merge this quickly, you should at least add an warning in the docs saying that the field must be mapped set as nullable.





[DDC-3846] [GH-1473] Docs fix ref and title Created: 24/Jul/15  Updated: 25/Jul/15  Resolved: 25/Jul/15

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

Type: Documentation Priority: Major
Reporter: Doctrine Bot Assignee: Marco Pivetta
Resolution: Fixed Votes: 0
Labels: documentation, headers, rst


 Description   

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

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

Message:

Pretty Ref and Fixed WARNING: Duplicate explicit target name

/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".
/doctrine2/docs/en/changelog/migration_2_5.rst:2: WARNING: Duplicate explicit target name: "pull request".

Fixed WARNING: Title underline too short

/doctrine2/docs/en/reference/second-level-cache.rst:622: WARNING: Title underline too short.
/doctrine2/docs/en/reference/caching.rst:89: WARNING: Title underline too short.






[DDC-3849] [GH-1476] Enhancement: Enable caching of dependencies between builds Created: 24/Jul/15  Updated: 25/Jul/15  Resolved: 25/Jul/15

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: Duplicate Votes: 0
Labels: build-speed, cache, ci, composer, travis


 Description   

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

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

Message:

This PR

  • [x] enables caching of dependencies as installed with Composer between builds


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

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





[DDC-3848] [GH-1475] Fix: Development dependencies are installed by default Created: 24/Jul/15  Updated: 25/Jul/15  Resolved: 25/Jul/15

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: Duplicate Votes: 0
Labels: ci, composer, travis


 Description   

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

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

Message:

This PR

  • [x] removes the `--dev` option when installing dependencies, as `development` dependencies are installed by default


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

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





[DDC-3847] [GH-1474] Fix: Remove unused imports Created: 24/Jul/15  Updated: 24/Jul/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 localheinz:

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

Message:

This PR

  • [x] removes apparently unused imports





[DDC-3845] Add logger to track information how much time hydration of entities was spent and how many entities was hydrated Created: 23/Jul/15  Updated: 23/Jul/15

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

Type: Improvement Priority: Major
Reporter: Dmytro Malyshenko Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: orm


 Description   

Maybe it worth to make a logger like Doctrine\DBAL\Logging which will track an information how much time was spent on a hydration of entities and how many entities were hydrated.

Because of lazy loading there could be hydrated a much more objects than it needed and it hard to track.

If a logger will be created, later in Symfony, for example, in doctrine/DoctrineBundle, it could be injected in Doctrine\ORM\Configuration and collected information might be displayed in a web profiler panel.

I've made a symfony bundle which implements the functionality - https://github.com/debesha/DoctrineProfileExtraBundle

Here https://github.com/debesha/DoctrineProfileExtraBundle/wiki I tried to explain why I think it is necessary.

If it will be considered to be worth to implement, I can make a coding myself and push it into hobodave/doctrine2.git






[DDC-3844] [GH-1472] Add test for MariaDB 5.5 and 10.1 on Travis Created: 23/Jul/15  Updated: 23/Jul/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 PowerKiKi:

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

Message:

This use the brand new supported addon mariadb (not yet officially announced).
This is unfortunately a bit verbose, but I don't think there is any
alternative because we cannot install the addon when testing against mysql
otherwise it would overwrite mysql install.






[DDC-3212] Remove ArrayHydrator logic Created: 14/Jul/14  Updated: 22/Jul/15

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

Type: Improvement Priority: Critical
Reporter: Marco Pivetta Assignee: Marco Pivetta
Resolution: Unresolved Votes: 0
Labels: hydration, hydrator


 Description   

The Doctrine\ORM\Internal\Hydration\ArrayHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ArrayHydrator.php ) is currently very messy and complicated due to the lack of actual Doctrine\ORM\UnitOfWork references when working with it, since we are not dealing with objects.

In order to reduce the amount of bugs and code duplication when working with array hydration, I would simply suggest making use of the Doctrine\ORM\Internal\Hydration\ObjectHydrator ( https://github.com/doctrine/doctrine2/blob/85fbf684363b932a4ebaf543ef059f9ee1e512b0/lib/Doctrine/ORM/Internal/Hydration/ObjectHydrator.php ) and its siblings, and then extracting data coming from the results in it as an array.

This could be a simple reflection-based extraction (pseudo):

class ArrayHydrator
{
    public function hydrateAllData()
    {
        foreach ($this->objectHydrator->hydrateAllData() as $object) {
            yield $this->extractData($object);
        }
    }
}

The point here is that array-based hydration is not the primary focus of the ORM, and users should probably rely on SQL only when they want array hydration.



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

Note: performance is one of our biggest requirements, and array hydration is meant to achieve that. As I stated above, plain SQL is probably better for this sort of operation, so the issue is more about deprecating the ArrayHydrator completely, providing utilities to manipulate SQL resultsets instead.

Comment by Claudio [ 22/Jul/15 ]

I know of some intern projects, where the ArrayHydrator is used. It is right, that an ORM should be about objects, but that also counts for ScalarHydrator, and SingleScalarHydrator, which also aren't Object hydrator. Isn't there a way to reduce the complexity of the ArrayHydrator without ObjectHydrator? It would be a shame when a project build up with DQL Queries need to switch partially to SQL.





[DDC-16] DQL Ignores properties of subclasses Created: 15/Sep/09  Updated: 22/Jul/15  Resolved: 24/Feb/13

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

Type: Improvement Priority: Minor
Reporter: Avi Block Assignee: Marco Pivetta
Resolution: Won't Fix Votes: 6
Labels: None

Issue Links:
Duplicate
is duplicated by DDC-1377 Doctrine doesn't understand associati... Closed
is duplicated by DDC-3342 Join with child tables Resolved

 Description   

I have a classes B and C which inherit from superclass A. I would like
to get a list of all A's but filter the list to ignore those in C
which have a property d set to 2.

select a from A where a.d == 2 fails because "d" is not a property of A.



 Comments   
Comment by Roman S. Borschel [ 31/Mar/10 ]

Thats indeed tricky. That syntax alone can, however, never work, because there might be several subclasses that have a field named "d", so Doctrine would not know which field you mean.

We might need special syntax for such constructs but I'm not sure it is worth it. If anyone has an idea, just shoot.

Alternatively, apart from using a native query, what about this DQL:

select a from A a where a.id not in (select c.id from C c where c.d = 2)
Comment by Benjamin Eberlei [ 01/Apr/10 ]

I am sorry, but isn't this sort of query a violation of object oriented programming, Accessing a Superclass A and checking for a property that exists on a certain child is not possible in any strict OO language without specific casting into the type beforehand.

Comment by Roman S. Borschel [ 01/Apr/10 ]

Thats why I said "we would need special syntax for such constructs", i.e. casting syntax

However, the alternative query I showed should work just fine for such purposes.

Comment by Menno Holtkamp [ 18/Jul/11 ]

+1 for this request.

When displaying data (stored in a database) to end-users using generated tables, server-side sorting and filtering on properties that belong to subclasses is a common task, for instance to provide the data presented in a JQuery Datatable: http://www.datatables.net.

For this purpose, DQL is great to generate the required queries dynamically. However, since properties of subclasses can currently not be 'accessed', sorting and filtering on these properties becomes impossible, or at least cumbersome to implement. Currently I have lifted/copied specific properties to a general 'value' property of the superclass, which CAN be used for ordering and filtering. Of course, this work-around significantly decreases the power of inheritance strategy in the originally envisioned model.

In Hibernate this seems to have been solved in HQL using downcasting, which seems a viable approach, but as Benjamin already mentioned not a best practice in a strict OO approach. Therefore a specific syntax might be required to hint on the to-be-expected casts:

For additional motivation of this subject, check a recent post of mine at the user groups: http://groups.google.com/group/doctrine-user/msg/caebf8139e06e01a

Comment by Avi Block [ 18/Jul/11 ]

Honestly I gave up on all of this a long time ago, and now use a CQRS approach. I make views, or denormalized tables for every view in my application, and just use straight SQL.

When I need to do creating or updating or whatever, I use doctrine.

Comment by Glen Ainscow [ 19/Jul/11 ]

I would like this as well (though my use case involves joining to the subclass).

Registration has one Opponent (superclass to Player and TeamSelection). I would like to count the number of registrations for a particular team within a specific tournament. For example:

SELECT COUNT(*)
FROM Registration r
INNER JOIN r.opponent CAST TeamSelection ts
INNER JOIN ts.team t
WHERE r.tournament = 1
AND t.name = "Team #1"
Comment by Glen Ainscow [ 19/Jul/11 ]

Thinking about this a bit more, it can actually improve query performance, as it would no longer be necessary to join the other subclasses. In other words, since you're casting the opponent to a TeamSelection, it's not necessary to join to the players table.

A cast should probably also restrict the result using the discriminator column, for example (SQL):

INNER JOIN opponents o ON o.id = r.opponent_d AND o.type = "TeamSelection"
Comment by Guilherme Blanco [ 15/Sep/11 ]

Possible solution:

SELECT p FROM CAST(Person AS User) p

Or:

SELECT a, p FROM Article a JOIN CAST(a.person AS User) p
Comment by Glen Ainscow [ 16/Sep/11 ]

If you're casting a Person (superclass) to a User (subclass), then shouldn't the alias be "u" and not "p"?

i.e. SELECT a, u FROM Article a JOIN CAST(a.person AS User) u

Comment by Benjamin Eberlei [ 16/Sep/11 ]

the alias is that, an alias, you can use whatever you want.

Comment by Glen Ainscow [ 16/Sep/11 ]

Yes I know that, I'm just making sure that I understand the syntax.

Comment by Jaka Jancar [ 18/Feb/12 ]

I just ran into a similar problem and am not sure the above cast solution would do.

I'm trying to do:

SELECT
    s
FROM
    Superclass s
WHERE
    s INSTANCE OF SubclassA OR
    s INSTANCE OF SubclassB AND s.foo = 'bar';

So I'd need to use CAST in a WHERE condition, not in the FROM/JOIN clause, e.g:

SELECT
    s
FROM
    Superclass s
WHERE
    s INSTANCE OF SubclassA OR
    s INSTANCE OF SubclassB AND (CAST s AS SubclassB).foo = 'bar';
Comment by Wladimir Coka [ 03/Apr/12 ]

Is there any workaround? Would be perfect if I could just:

 SELECT a, p FROM Article a JOIN CAST(a.person AS User) p 

(+1 for Guilherme Blanco possible solution)

Comment by Wladimir Coka [ 04/Apr/12 ]

I was trying a workaround:

Before executing the dql query, I change the mapping info of the association to the concrete type that I was going to use. Like this:

        $cmf = $this->em->getMetadataFactory();
        $class = $cmf->getMetadataFor("Article");
        $class->associationMappings["person"]["targetEntity"]="User";

But now my problem is that I'm actually using an inverse side (in query where this is needed), so when I change the targetEntity, the sql join that is generated, is using the table of the concrete class (User in this case) and not the base class (Person)

class Person {
...
	/**
	 * @OneToOne(targetEntity="Order",cascade={"persist"})
	 * @JoinColumn(name="order_id", referencedColumnName="orden_id")
	 */
	private $order;
...
}

class Order {
...
    /**
     * @OneToOne(targetEntity="Person", mappedBy="order")
     */
    private $person;
...
}

The SQL generated is joining as if the "user" table has orden_id field

Comment by Marco Pivetta [ 24/Feb/13 ]

I am closing this one.

The requirement of this issue is basically violating OO principles.

If you really need to filter across multiple child-entities in your inheritance, then try something as following instead:

SELECT
    r
FROM
    Root r
WHERE
    r.id IN (
        SELECT
            c.id
        FROM
            Child c
        WHERE
            c.field = :value
    )

Up-casting is not really a viable solution anyway, since it would be even more weird to cast in DQL and then have hydration still retrieve the root entity type.

Comment by Bogdan Yurov [ 17/Jul/14 ]

@Marco You are wrong. There is no way to do this. It is just not wise to deny a feature just because it violates OO principles when this is the only method.

There are usecases, when we have nothing to do. For example, we are searching through the whole table in STI. We use quick filters like "Like" so there is not need in difficult indexes/additional tables for them. We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.

This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.

Comment by Marco Pivetta [ 17/Jul/14 ]

It is just not wise to deny a feature just because it violates OO principles when this is the only method.

We are working on an ORM (Object-Relational-Mapper), therefore Object-Orientation is first-class citizen and prioritized over everything else in the ORM.

There are usecases, when we have nothing to do.

There are use-cases for everything, but that doesn't mean that they should clutter the tool. This does not only apply to Doctrine ORM. An edge case functionality that has multiple workarounds and that cannot be implemented correctly within the tool does NOT need to land in the tool.

I provided a workaround that respects the OO and ORM rules and works also with the OO paradigm. Here is a pseudo-code description of what the DQL I pasted above does:

  • select all objects that are instance of Child by $someCriteria
  • select all objects that are instance of Root
  • iterate over Root instances and filter out those that are not in the results of the first selection

We CAN NOT in ANY way overcome this limitation when we need to use fields of different classes.

Yes you can: there's SQL. SQL is a "structured query language" that is weakly typed and allows this sort of operation natively. This is a problem of the SQL domain, and it should be solved with SQL whenever the DQL becomes too complex/limited. Don't try to stuff a feature that is only possible in the SQL domain into DQL just because they look similar.
They are not the same thing.

This is certainly not a bug, when we may say "WONT FIX" and just ignore all those people who face it.

We are not ignoring the problem: we just point you to the right scope/tools to solve it. DQL has one way of solving it, which may or may not be viable to you. SQL has another way of solving this same problem, and it's not going to be implemented in DQL because DQL is statically typed, and upcasts and type juggling are not going to land in DQL.

Comment by Bogdan Yurov [ 17/Jul/14 ]

If we provide a workaround, is there any way to merge it to master branch? What we can do to vote up this feature?

Comment by Marco Pivetta [ 17/Jul/14 ]

Bogdan Yurov we already tried looking into this multiple times.

The only "clean-ish" solution would be to support upcasting somehow, and the effort and complexity derived from it is not worth it.

Comment by Bogdan Yurov [ 17/Jul/14 ]

@ocramius
What about "CAST()" construction? You were talking about OO, but there are some languages, that could argue with you.

For example, Delphi. It supports casting manually to selected type (for example TObject -> TButton). Does it break best violates OO principles too? No, of course.
Another example is Java. It has exactly same language construction for exactly same purpose. Is doctrine more concentrated on OO principles than Java or Delphi?

Comment by Marco Pivetta [ 22/Jul/14 ]

Bogdan Yurov I think Guilherme Blanco is thinking of providing a cast syntax.

Comment by Adrian Grayson [ 07/Jul/15 ]

"For example, Delphi. It supports casting manually to selected type (for example TObject -> TButton). Does it break best violates OO principles too? No, of course.
Another example is Java. It has exactly same language construction for exactly same purpose. Is doctrine more concentrated on OO principles than Java or Delphi?"

I agree. I fail to see how a type safe CAST() violates OO. We're not talking about dangerously casting anything, at least not in theory. It's polymorphism.

Comment by Bogdan Yurov [ 22/Jul/15 ]

Is there any chance that this would be implemented?

Comment by Marco Pivetta [ 22/Jul/15 ]

Unlikely right now.

Comment by Bogdan Yurov [ 22/Jul/15 ]

Is it worth it to try to implement such behavior? I am not well aware of Doctrine internals thus I can not chose what to do. Would it require rewriting of doctrine kernel and major changes, or it could be implemented somehow without much patching?

Comment by Marco Pivetta [ 22/Jul/15 ]

Implementing it is not the problem. The problem is that it violates ORM invariants that we want to keep.





[DDC-3842] [GH-1471] Platform built twice on closed connections Created: 21/Jul/15  Updated: 22/Jul/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: close, connection, platform


 Description   

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

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

Message:

There is a loop when a closed connection is asked for its Database Platform, in which the resulting Platform object gets overwriten by a new one and all modifications made in the postConnect event is lost.

The commited test adds the event BEFORE the connection gets opened automatically by the OrmFunctionalTestCase setUp method. I know this is not a common test scenario, but I had to make this hack in order to reuse all the other FunctionalTestCase stuff.

I believe this only happens in Drivers that implement VersionAwarePlatformDriver, as I could not reproduce it with sqlite.

I believe what's happening is:

  • `Connection` tries to `detectPlatformDriver`
  • As connection is closed, `getDatabasePlatformVersion` tries to `$this->connect()` it
  • `Connection::connect()` has a `null` on `$this->platform` because it didn't finish detecting, so it tries to detect again
  • This time the connection is opened, so `detectPlatormDriver` succedes.
  • `Connection` fires the event
  • The rest of the first `detectPlatformDriver` call executes, overriding `$this->platform`

I was using the postConnect event to add types only when the connection is opened, instead of adding them every time I constructed the EntityManager, to prevent connections from being opened every time.






[DDC-3843] indexBy collection loses index key after calling a ->matching(criteria) on it Created: 22/Jul/15  Updated: 22/Jul/15

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

Type: Bug Priority: Minor
Reporter: Matteo Orefice Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 0
Labels: collection, orm
Environment:

Linux Debian (7.8) NGINX (1.8.0) PHP (5.5.25-1~dotdeb) MySQL (5.6.24-72.2)



 Description   

When I retrieve a filtered collection of entities which has indexBy attribute it loses index keys in the result. Before calling matching() method i tried to call toArray() and It solved the problem, I don't know if it is a bug .

class Entity {
/**
     * @var ArrayCollection
     * @ORM\OneToMany(targetEntity="Entity\Arcansel\BasketItem",mappedBy="userSession",indexBy="id",cascade={"persist","remove","merge"})
     */
    protected $basketItems;


// Some comments here
public function getBasketItems()
    {
        $date = DateTime::newDateTimeUniversal();
        $criteria = Criteria::create()->where(Criteria::expr()->gt("addTime",$date));
        // next line of code prevents returned collection to lose indexBy keys
        $a = $this->basketItems->toArray();
        return $this->basketItems->matching($criteria);
    }
}





[DDC-3841] [GH-1470] [CI] Added dev requirement for "doctrine/coding-standard" Created: 20/Jul/15  Updated: 21/Jul/15

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

Type: Improvement Priority: Minor
Reporter: Doctrine Bot Assignee: Benjamin Eberlei
Resolution: Unresolved Votes: 1
Labels: CI, CS, Tools

Issue Links:
Reference
relates to DDC-585 Create a coding standards document Open

 Description   

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

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

Message:

Q A
-------------
Bug fix? no
New feature? yes
BC breaks? no
Deprecations? no
Tests pass? yes
Fixed tickets
License MIT
Doc PR
  • Added dev requirement for ```doctrine/coding-standard```.
  • Updated Travis config in order to use the new requirement within
    ```before_script``` lifecycle.


 Comments   
Comment by Phansys [ 20/Jul/15 ]

Take this as a probe of the current status of the Doctrine's CS. IMO, we should decide how to proceed in order to get a clean codebase, and I think we should apply some tool like PHP-CS-Fixer or update PHP_CodeSniffer to 2.0 in order to achieve the same feature.

Ping @Ocramius.

Comment by Marco Pivetta [ 21/Jul/15 ]

Phansys I already replied on the PR: needs CS changes before merging, and other PRs take priority first.

Comment by Phansys [ 21/Jul/15 ]

Marco Pivetta, auto CS fixes aren't available with PHP_CodeSniffer at 1.x version (they are in yet unreleased 2.x); that is why I created this PR https://github.com/doctrine/doctrine2/pull/1460 using PHP-CS-fixer, while I've also added a rule for Doctrine's logical NOT CS: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/1303.
IMO, at some point we should use any of these tools to ensure all the CS rules are respected.





Generated at Tue Jul 28 17:48:33 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.