On Tue, 15 Jan 2008, Ash Berlin wrote:
> > On Jan 13, 2008, at 1:20 PM, Jess Robinson wrote: > >> >> On Sat, 12 Jan 2008, Ash Berlin wrote: >> >>> >>> On Jan 8, 2008, at 12:05 PM, Ash Berlin wrote: >>> >>>> Right then. >>>> >>>> A while back (sometime in December) I asked for commit to the repo >>>> to work >>>> on refactoring SQL::Translator::Diff. >>>> >>>> I have no done what I set out to do. You can see my code here: >>>> http://sqlfairy.svn.sourceforge.net/viewvc/sqlfairy/branches/diff-refactor/sqlfairy/ >>>> >>>> Some of the things I did: >>>> >>>> * Diff is no longer one huge monolithic function. >>>> * Added more tests for diff >>>> * When producing diffs for MySQL you will (by default) get SQL >>>> like this: >>>> >>>> ALTER TABLE employee DROP FOREIGN KEY FK5302D47D93FE702E, >>>> DROP COLUMN job_title, >>>> ADD CONSTRAINT FK5302D47D93FE702E_diff_1 >>>> FOREIGN KEY >>>> (employee_id) REFERENCES person (person_id); >>>> * SQLite can also do remove columns (by creating a temp table as >>>> shown in >>>> http://sqlite.org/faq.html#q11 >>>> * Columns can be renamed if the new schema is from a form that can >>>> have >>>> metadata (which is pretty much anything but an SQL file.) It does >>>> this my >>>> looking at renamed_from in the $field->extra >>>> >>>> I would now like to merge this back to trunk. Since this is a major >>>> refactor I thought it best to get other (core) people to review it >>>> first. >>>> >>>> The one major change which I had to do was how/where the MySQL >>>> producer >>>> normalizes its column types and sizes. As a side effect of this >>>> each field >>>> has an accessor for 'parsed_field' which will be the type, size, >>>> list etc >>>> *exactly* as parsed from the original SQL (or other) source. >>>> Without this >>>> diffing a DBIx::Class::Schema against an SQL file was just plain >>>> impossible. >>>> >>>> Please review the changes. If anyone would like a diff file of all >>>> the >>>> changes from trunk and is too lazy to do it themselves, let me >>>> kniw and >>>> I'll post one of those too. >>>> >>>> Cheers, >>>> ash >>>> >>> >>> Yes replying to my own message is bad form - so sue me ;) >>> >>> Anyway - here is a diff for ppl to peruse. (just to be clear, I'm >>> not asking >>> anyone to apply this patch, just look over it and give feedback so >>> that I can >>> merge these changes back to trunk) >>> >> >> >> Woo, I'm impressed! >> >> Some ponderings: >> >> I see the default set of conversions from types to generic types in >> Schema::Field, can each parser also supply a generic type as well? > > Yes, but not that cleanly currently. See the very end of > http://sqlfairy.svn.sourceforge.net/viewvc/sqlfairy/branches/diff-refactor/sqlfairy/lib/SQL/Translator/Parser/MySQL.pm?view=markup >> >> >> Are any of the unchanged parsers/producers now incompatible? > > No, they should work as before. But some more people to test this > would be good > >> >> >> The equals() sub tests whether sql_data_type is unset, can that ever >> happen if data_type always sets it? > > sql_data_type can be 0 if you use a DBMS specific type such as MySQL's > ENUM or SET types. > >> >> >> I'm not even going to re-read the actual diffing code.. was scary >> enough >> the first time.. ;) >> >> Thanks Ash! >> >> Jess >> > Well, looks like all tests pass to me, and no shouting, so go for it! Jess ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- sqlfairy-developers mailing list sqlfairy-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sqlfairy-developers