Thanks for the clarification and for your time. Have updated the query to fully populate the entity.
Best regards, Andreas On Friday, August 25, 2017 at 9:12:59 AM UTC+2, Marco Pivetta wrote: > > On Wed, Aug 23, 2017 at 9:29 AM, Andreas Goetz <[email protected] > <javascript:>> wrote: > >> Hi Marco, >> >> On Wednesday, August 23, 2017 at 9:23:33 AM UTC+2, Marco Pivetta wrote: >>> >>> You are filtering a fetch-joined association: that will break hydration. >>> We never manager to add error messages for this type of query, since that >>> would be a BC break, but the DQL is invalid. >>> >> >> I realize I'm filtering here, so I'd have the following questions: >> >> a) after the filtering I'm running the "full" query again- shouldn't that >> work independently, even more so as it actually hits the database? >> > > No, because results that are in the `UnitOfWork` are still considered > "valid" and potentially modified by the consumers of the current > `UnitOfWork`. The `UnitOfWork` will not overwrite in-memory data due to > this reason. > > b) if the filtering query per se is invalid (I think that's what you're >> saying?)- how would I properly retrieve a populated entity per joined >> filtering criteria? >> > > Something like following will work (pseudo-DQL): > > SELECT a, b > FROM A a > JOIN a.b b > JOIN a.b c > WHERE c.someField = "blah" > GROUP BY a.id, b.id > > That would allow the filtering, yet keeping `A` instances hydrated > correctly, as the filtering is applied on a non-hydrated association being > selected. > > c) in terms of BC- since this issue only appeared after >1 year in >> production (yikes!)- why not introduce error messages with e.g. ORM 2.6? >> > > Because that's a BC break anyway: a lot of people may actually be relying > on broken hydration by their own design. Every change applied to the ORM > has an effect on hundreds of thousands of projects. > > If you want to give it a shot, we can introduce it in ORM v3, which is the > current `develop` branch on https://github.com/doctrine/doctrine2 > > >> Much appreciated, >> Andreas >> >> >> >>> On 23 Aug 2017 9:15 AM, "Andreas Goetz" <[email protected]> wrote: >>> >>> I have a simple ER diagram with entities and properties 1:n. Retrieving >>> an entity by its uuid will also obtain all it's properties: >>> >>> $dql = 'SELECT a, p >>> FROM Volkszaehler\Model\Entity a >>> LEFT JOIN a.properties p >>> WHERE a.uuid = :uuid'; >>> >>> $q = $em->createQuery($dql) >>> ->setParameter('uuid', $uuid); >>> >>> $entity = $q->getSingleResult(); >>> >>> var_dump($entity->getProperties()); // all properties >>> >>> Now, for some cases I'm identifying the entity by name (and make sure >>> it's of public type), obtain the uuid and then pass it through the above >>> query: >>> >>> $dql = 'SELECT e, p >>> FROM Volkszaehler\Model\Entity e >>> LEFT JOIN e.properties p >>> JOIN e.properties public >>> WHERE p.key = :key >>> AND p.value = :name >>> AND public.key = :key2 >>> AND public.value = 1'; >>> >>> $q = $this->em->createQuery($dql) >>> ->setParameter('key', 'title') >>> ->setParameter('name', $name) >>> ->setParameter('key2', 'public'); >>> >>> $entity = $q->getSingleResult(); >>> >>> Now, calling the first query with the UUID, only a single property is >>> returned but not all of them as expected: >>> >>> var_dump($entity->getProperties()); // only 'title' property is shown >>> >>> SQL trace shows that the exact same queries are executed, only in the >>> 2nd case the properties apparently are swallowed by the ORM. >>> >>> Any idea what's wrong here? >>> >>> Thanks, >>> Andreas >>> >>> -- >>> >>> > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > -- You received this message because you are subscribed to the Google Groups "doctrine-user" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/d/optout.
