Ok, I see. Thanks Benjamin for the quick explanation.
On Friday, 17 October 2014 12:26:34 UTC+2, kontakt wrote: > > 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] > <javascript:>> 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] <javascript:>. >> To post to this group, send email to [email protected] >> <javascript:>. >> 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.
