In my model I used UUID as the generator strategy for my id:
@GeneratedValue(strategy="UUID")
It works for creating my UUID but when I add some changes to my model and run
orm:generate-entities --generate-annotations="true" models/
it throws the following exception:
"[InvalidArgumentException]
Invalid provided IdGeneratorType: 6 "

Looking at the EntityGenerator.php I saw that the UUID type is not (yet?) in there. When I add it to the function getIdGeneratorTypeString() everything works fine...
I'm new to Doctrine so I'm not sure if this is actually a bug, but it seems weird to me

When calling clear on a PC that has no owner (e.g. because it was cloned), it can't be deleted as there is no metadata available (that's essentially the exception mentioned in the ticket). In these cases, I think it shouldn't be scheduled for deletion, but please have a look as my knowledge of the ORM internals is limited.

> PersistentCollection::matching() always returns empty collection, when passed criteria's expression is created using ExpressionBuilder::isNull()
> This happens because expression created by ExpressionBuilder::isNull() is wrongly translated to SQL using '=' operator instead of 'IS NULL'.
> If the collection is already loaded, result is as expected.

In SqlWalker::walkJoin(), SqlWalker::walkRangeVariableDeclaration() can be
called which may produce an 'ON' clause if the entity inheritance type is
JOINED. As walkJoin() may then produce another ON clause, this results in
invalid SQL (e.g. '... ON foo = bar ON (baz = quux) ...' when the inheritance
type is JOINED.

This adds a test and a fix for the problem, by checking for an inheritance type
of JOINED in walkJoin() and using AND instead of ON in the appropriate place.

It seems like this part of the code is begging to be refactored. This is my
first foray into Doctrine internals and can't see a way to do this without
stomping all over the rest of the code, but this section seems ripe for cleanup
by somebody who is familiar.

Currently, the DocBlock annotations for member variables contain the variable name as description which is redundant and should be removed. Furthermore the class is annotated with the FQN instead of just the name. This makes automatically generated documentation quite ugly.

I use the resolve target entity listener quite often for generic code. However I found an issue with ManyToMany relationships, when the target entity is modified by the listener.

The problem is that the _validateAndCompleteManyToManyMapping in PersistentCollection duplicate the joinTableColumns, so this means that when creating an entity, Doctrine send twice the number of parameters, which of course fail.

While executing updates on an entity scheduled for update without a change-set, an "Undefined index" notice is raised.

This issue will occur when you manually call $em()->getUnitOfWork()->scheduleForUpdate() on an entity that hasn't changed. The entity will be included in UnitOfWork::$entityUpdates, but because there are no changes, its oid will not be included in UnitOfWork::$entityChangeSets.

I know I'm misusing scheduleForUpdate() a bit in this case, but the notice can easily be prevented with a !empty().

For example an Album could be related to any other similar albums. An album entity would have a property 'relatedAlbums' which is an ArrayCollection. Similarly, I could be working on a CMS where any piece of content could be related to any other in order to show a "related content" or "related posts" style list on a web page.

Using Symfony 2.1 and a Symfony Form with FormBuilder make sure to use the 'by_reference' => false to call the setter for the property. In the setter for the property: https://gist.github.com/3879169

The class 'Doctrine\ORM\Persisters\ManyToManyPersister' was not found in the chain configured namespaces Gedmo\Tree\Entity, Gedmo\Translatable\Entity, MyProject\Bundle\AdminBundle\Entity, MyProject\Bundle\Common\SiteBundle\Entity, MyProject\Bundle\Common\ContentBundle\Entity, FOS\UserBundle\Entity

500 Internal Server Error - MappingException

Stack Trace

in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/MappingException.php at line 38
*/
public static function classNotFoundInNamespaces($className, $namespaces)

at MappingException ::classNotFoundInNamespaces ('Doctrine\ORM\Persisters\ManyToManyPersister', array('Gedmo\Tree\Entity', 'Gedmo\Translatable\Entity', 'MyProject\Bundle\AdminBundle\Entity', 'MyProject\Bundle\Common\SiteBundle\Entity', 'MyProject\Bundle\Common\ContentBundle\Entity', 'FOS\UserBundle\Entity'))
in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/Driver/MappingDriverChain.php at line 114
at MappingDriverChain ->loadMetadataForClass ('Doctrine\ORM\Persisters\ManyToManyPersister', object(ClassMetadata))
in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/orm/lib/Doctrine/ORM/Mapping/ClassMetadataFactory.php at line 112
at ClassMetadataFactory ->doLoadMetadata (object(ClassMetadata), null, false, array())
in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php at line 302
at AbstractClassMetadataFactory ->loadMetadata ('Doctrine\ORM\Persisters\ManyToManyPersister')
in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/common/lib/Doctrine/Common/Persistence/Mapping/AbstractClassMetadataFactory.php at line 205
at AbstractClassMetadataFactory ->getMetadataFor ('Doctrine\ORM\Persisters\ManyToManyPersister')
in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php at line 268
at EntityManager ->getClassMetadata ('Doctrine\ORM\Persisters\ManyToManyPersister')
in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/ManyToManyPersister.php at line 169
at ManyToManyPersister ->_getDeleteSQL (object(PersistentCollection))
in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/orm/lib/Doctrine/ORM/Persisters/AbstractCollectionPersister.php at line 89
at AbstractCollectionPersister ->delete (object(PersistentCollection))
in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/orm/lib/Doctrine/ORM/UnitOfWork.php at line 328
at UnitOfWork ->commit (null)
in /opt/local/apache2/htdocs/projects/my-project/vendor/doctrine/orm/lib/Doctrine/ORM/EntityManager.php at line 355
at EntityManager ->flush (null)
in kernel.root_dir/cache/dev/jms_diextra/doctrine/EntityManager_5075974d574d6.php at line 362
at EntityManager ->flush ()
in /opt/local/apache2/htdocs/projects/my-project/src/MyProjectBundle/Common/ContentBundle/Controller/ContentController.php at line 170
at ContentController ->updateAction (object(Request), '3')
at call_user_func_array (array(object(ContentController), 'updateAction'), array(object(Request), '3'))
in kernel.root_dir/bootstrap.php.cache at line 1421
at HttpKernel ->handleRaw (object(Request), '1')
in kernel.root_dir/bootstrap.php.cache at line 1385
at HttpKernel ->handle (object(Request), '1', true)
in kernel.root_dir/bootstrap.php.cache at line 1561
at HttpKernel ->handle (object(Request), '1', true)
in kernel.root_dir/bootstrap.php.cache at line 612
at Kernel ->handle (object(Request))
in /opt/local/apache2/htdocs/projects/my-project/web/app_dev.php at line 28

exception 'Doctrine\DBAL\Schema\SchemaException' with message 'There is no column with name ' column2' on table 'myTable'.

This can be very confusing, especially if (by any chance) you have a line return just on the space in the command line: you never see the space in the exception message.

It seems that YAML allows spaces in lists (http://en.wikipedia.org/wiki/YAML#Lists), but this line doesn't seem to be a YAML list. If it is parsed by Doctrine (split on ","), spaces should be ignored (or trimmed).

I realise this is very hand wavy and if you require some more information or test cases then I can see about that.

However, just to get the issue logged, as I just spent 3 hours reverse engineering the doctrine code to find this, and it may help someone else.

Basically when reading the XML mapping data from generated XML files the orphan-removal value was being incorrectly parse as 'true' when it was set to 'false' in the mapping file.

I think this is because the XML parser was parsing the attribute as an object and when it was casted a boolean this meant the value became true. To overcome this I first cast the value as a string, and then to a bool.

I have ommitted the foreign key definitions for better readability. When I execute doctrine:mapping:convert (in Symfony2, but it seems it's a Doctrine2 issue), I get the following error:

[Doctrine\ORM\Mapping\MappingException]
Property "user" in "Project" was already declared, but it must be declared only once

I have tracked down the issue to be caused by the existence of `user_id` in the project table. So basically, because `project_conversation` references `project` which in turn references `user`, `project_conversation` reference to `user` is perceived as duplicate.

I don't think that this should be the expected behavior though. user_id in `project` references the creator of the project while user_id in `project_conversation` references the creator of the conversation and thus I think the schema is valid.

I am using the same custom TsvectorType with simple entities and even Mapped Superclasses and it works perfectly, however on InheritanceType("JOINED") method convertToDatabaseValueSQL() is never called :/
Hope someone knows how to fix this.
Thank you.

@Fabio thanks for looking into my problem
I attached test where you can detect the problem.

It was quite strange, all i did was changed column that uses custom type to array and some minimal convertToDatabaseValue and convertToDatabaseValueSQL logic and convertToDatabaseValueSQL was never called.

One more thing i noticed, this bug only appears on persist and not on merge.

The only way to update this field in postgresql is to use postgresql function to_tsvector('some text').
And everything works fine, if i persist simple entity, this method transforms insert query as needed:

But when i use inheritance, then by some reason convertToDatabaseValueSQL method is not called and tsv field is updated with simple text as returned by convertToDatabaseValue() method.
I modified the Ticket Test so that you can see exact moment of when it is not called, which is exactly my problem.

The query build by pager to get the subset of PKs to fetch produces wrong results on potgresql (and probably any database), that conforms to the SQL standard. The standard says, that if you wish to have the results in specific order, then you have to specify that by using an ORDER BY clause. If such a clause is not present the database can return the results in whatever order it sees fit.

SELECT DISTINCT id FROM (
SELECT id, name FROM test ORDER BY name
) dctrn_result
LIMIT 5 OFFSET 0

Now there is nothing wrong with this modified query per se, but there is no ORDER BY clause in the outer query so according to the standard the DB can choose whatever order it seems fit. Now mysql chooses the same order, but postgresql does not and it's probably not the only DB doing so.

If you are interested in the results, this is the output I'm seeing:

postgresql: 8,4,1,5,3

mysql : 2,6,4,1,5

I and my coworker came to the standard compliant solution it was also tested on the dataset above on both postgresql and mysql and it produced equal results. We have found only one corner case this won't work and IMHO that can't be fixed. The problem is when you do a sort on a field from a table that is in 1:n relation to the main table.. e.g tables posts and tags, where one post can have a multiple tags and you want your results sorted by a tag.

Recipe for a correct query is:

remember the ORDER BY fields from original query and then remove them

wrap the original query with a DISTINCT query, but add the fields from ORDER BY to the SELECT part of that query and add the whole ORDER BY to the end of it, also add the PK to the order by clause, and add the LIMIT clause

I've just been bitten by the "corner case" described above, "the problem is when you do a sort on a field from a table that is in 1:n relation to the main table.. e.g tables posts and tags, where one post can have a multiple tags and you want your results sorted by a tag.".

This is a pretty significant bug, as the end result is that data that should come back from the query doesn't. While there probably isn't a good universal workaround, the MySQL behaviour before this was already correct because the outer query was returning the ids in the same order as the internal query (even though it isn't required to by the standard). Is it possible to avoid having this apply to MySQL so that it doesn't introduce an additional bug in an attempt to fix an issue that doesn't apply to that platform anyway?

@Liam As you can se above the same applies to mariadb and if you look at the issues on the githubs doctrine project page you'll see that there is the same problem with newer mysql releases. AS I've written above. this corner case cannot be solved.

Thanks Miha. I couldn't find this on the github page so didn't realise that it was affecting some newer MySQL releases (it didn't seem to affect mine, 5.5). If that's the case, then as you point out it can't even be fixed for MySQL.

Perhaps the lack of support could be more explicit instead? If you attempt to use the paginator with two FROM tables then a RuntimeException is thrown, if we did the same when the ORDER BY conditions applied to tables joined via a 1:m relationship then at least users would know that things were going wrong rather than getting strangely unpredictable results.

In the Doctrine 2.1 versions the method EntityRepository::findBy() accepts additional parameters for ordering, limit and offset.
Great feature! (While waiting for it I extended the EntityRepository class and implemented these parameters myself using a QueryBuilder.)

It would be nice for the method EntityRepository::findOneBy() to accept an additional parameter for ordering as well. It could use the following signature:public function findOneBy(array $criteria, array $orderBy = null);
This would be useful for various cases, for example: finding the newest blog-post.

And maybe update EntityRepository::findAll() as well with the signature:public function findAll(array $orderBy = null);

Can it also be added to "findOneBy"? It would come in very handy for the use case above (for example: finding the newest blog-post).
Otherwise, I think we are limited to the alternative using "findBy" with the orderBy parameter (thus fetching all entries, followed by returning only the first/last) or using a native query.