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?
Are any of the unchanged parsers/producers now incompatible?
The equals() sub tests whether sql_data_type is unset, can that ever
happen if data_type always sets it?
I'm not even going to re-read the actual diffing code.. was scary enough
the first time.. ;)
Thanks Ash!
Jess
-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://ad.doubleclick.net/clk;164216239;13503038;w?http://sf.net/marketplace
--
sqlfairy-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlfairy-developers