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
>

For those of you that want to try out the code, there is a tarball at 
http://perlitist.com/static/dump/SQL-Translator-0.0899_01.tar.gz

-------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlfairy-developers

Reply via email to