http://www.doctrine-project.org/jira This file is an XML representation of an issue en-us 5.2.7 850 21-02-2013 http://www.doctrine-project.org/jira/browse/DMIG-30 Doctrine Migrations <p>Currently when using :migrations:diff the generated output will use addSql() exclusively. However there has to be a way to generate changes on the schema objects themselves by using the SchemaDiff objects and generating code from them.</p> DMIG-30

Make :migrations:diff smart and generate Schema object changes, not SQL directly

New Feature Major Open Unresolved Benjamin Eberlei Benjamin Eberlei Wed, 16 Nov 2011 22:34:01 +0000 Fri, 17 Feb 2012 06:19:43 +0000 2 3 <p>I think this would be something that would greatly increase the usefulness of migrations.</p> <p>After looking things over, I think doing something like this could work:</p> <ul> <li>Instantiate an instance of Doctrine\ORM\Tools\Comparator, and retrieve a Doctrine\DBAL\Schema\SchemaDiff using $comparator-&gt;compare($fromSchema, $toSchema);</li> <li>Iterate over each of the SchemaDiff's properties to retrieve new tables, dropped tables, columns, indexes, etc to generate both up and down code</li> </ul> <p>It seems fairly simple, but I get kind of lost thinking about how it can be tested.</p> <p>Another option, which may in the end be easier but more dirty, is to create a 'PhpPlatform' that only actually implements the getCreateTableSQL, getDropTableSQL, etc methods of Doctrine\DBAL\Platforms\AbstractPlatform.</p> <p>I've gone and followed what I outlined in my last comment, but there is a small snag.</p> <p>Comparator and SchemaDiff check for schema changes that are not possible to make using public methods. An example is a dropped index. Both Comparator and SchemaDiff support dropping indexes, but there is no Table#dropIndex to actually make it happen. </p> <p>However, if you use Reflection to modify the underlying Table#$_indexes array, then the proper SQL will be generated by SchemaDiff. Terrible and dirty, I know. We should do something about it <img class="emoticon" src="http://www.doctrine-project.org/jira/images/icons/emoticons/smile.gif" height="20" width="20" align="absmiddle" alt="" border="0"/> Should I create a ticket?</p> <p>Anyway, I've attached a patch (based on the current master, 9e81984) of what I've come up with. I <em>think</em> I've covered everything. This will even generate code to drop indexes and foreign keys (using Reflection). I've tried it on a schema of around 90 entities and it works beautifully. Of course, it's definitely not done or ready, but I wanted to see what was thought about what I've done.</p> <p>Finally, what would be considered an acceptable test for this kind of thing? I suppose if I refactor all of the code generating bits into individual methods, I could pretty easily test for expected output. Am I on the right track?</p> <p>edit: by the way, use <tt>migrations:diff --no-platform</tt> to generate the migration</p>