David Buchmann
David Buchmann
i can't think of a good reason why this should be forbidden, so i agree. note that for hierarchy relations (parent, children), we can't limit to locale. neither for referrers....
well, the referrers are done on phpcr level. and child translation strategy means translated fields are stored in a translation child node of the main node of the document. so...
is it ok if we remove the 1.2 milestone? i guess this is not a blocker?
i guess we did not have it because doctrine ORM thinks in database tables too much. with phpcr-odm it seems a valid use case to support this, and the resulting...
could we select from a bunch of different node types in that case or is that not supported in jcr sql2?
good point dan. i think if the documents in the original example all share a common ancestor, it would work like this: ``` php $qb->from('a')->documents('AppBundle\Document\TaggableContent'); $qb->where()->field('a.tags')->contains('foo'); ``` as the query...
yeah, ideally we would map traits as mixins and allow to query for traits too.
not that i would be aware of. if you want to work on it, please let us know.
hm, i think the fact that a document is translateable should be inherited too. with B extends A , A translatable and B adding nothing translatable, findTranslation should still have...
ach, sorry. yeah, it would make a lot of sense to cascade first and then check whether the document itself is translatable.