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

Reply via email to