Hi, you are right, depending on the database there is optimization potential. This has been working this way forever and before I joined the project. Only Roman can say something about the intentions, but he is not contributing anymore.
One reason i could think of is that calculating this based on the entities requires much more computation, and might cause the same computation over and over again in the case of bulk processing. greetings Benjamin On Fri, Oct 17, 2014 at 12:04 AM, Marc J. Schmidt <[email protected]> wrote: > Hi folks, > > I'm trying to learn some internals of Doctrine and wonder I may ask here a > question about the calculation of commit order and SQL generation. > > I've seen there a topological sorting calculator: > > > > https://github.com/doctrine/doctrine2/blob/master/lib/Doctrine/ORM/Internal/CommitOrderCalculator.php > > This class sorts entity classes by its dependencies that is provided by the > `associationMappings`, so the correct persistenter is called at the right > time. > Means right outer dependencies will be handled first, then the class that > holds > those dependency. Example list of persist() calls of UnitOfWork: > > car1 > owner1 > owner2 > car2 > > > You'll get (probably inverted) list from CommitOrderCalculator like: > > Owner > Car > > > The first question is: Why does doctrine sort the commit order by classes > and not the actual entity graph it could generate by using the information > of > UnitOfWork and `associationMappings`? > > However, after digging into Doctrine with my debugger, I saw Doctrine > generates for > each entity a separate INSERT query, even if each identifier is known > using sequences in PostgreSQL. I also discovered that when having a > (optional) > circular dependency between entities Doctrine resolves those always with a > 'INSERT without FK' value and later a 'UPDATE SET FK=x' strategy, even when > a circular dependency is not given in *this* commit-round. (but of course > it might > happen in the next flush/commit round). This is actual the result of not > using > a entities graph to resolve dependencies but only the associationMappings > and simple topological sorting. > > Is there a concrete reason why Doctrine has chosen this particular way to > resolve > relations/dependencies? I only wonder because this implementation does not > utilize maximum performance of various databases using bulk insert etc, but > rather suffers actually more from the overhead it generates. > > Thanks. > > Greetings, > Marc > > > -- > 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 http://groups.google.com/group/doctrine-user. > For more options, visit https://groups.google.com/d/optout. > -- 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 http://groups.google.com/group/doctrine-user. For more options, visit https://groups.google.com/d/optout.
