RE: [sqlfairy-developers] Refactoring various bits..

[Chris H. <ch...@al...>]

> -----Original Message-----
> From: sql...@li...=20
> [mailto:sql...@li...] On=20
> Behalf Of Jess Robinson
> Sent: Wednesday, 03 May, 2006 15:44
> To: sql...@li...
> Subject: [sqlfairy-developers] Refactoring various bits..
>=20
>=20
> Hi folks,
>=20
> Just wanted to run some things by other people:
>=20
> I've extracted out the bits of sqlt-diff that do the actual=20
> diffing, and put them in a package called=20
> SQL::Translator::Diff. Any complaints on the name? So far it=20
> just has the one work sub that takes schema source, target,=20
> options etc.. and sqlt-diff uses it.
>=20
> Ideally I'd like it to somehow ask the Parsers when it needs=20
> information like "what do they call ALTER TABLE=20
> CHANGE|MODIFY|ALTER COLUMN", etc.=20
> Maybe Parser.pm should have some stub methods for a template=20
> string to change a column, and so on?

Don't know about the templating specifics, but everything else sounds
great to me. I've advocated the exact same things, but couldn't justify
the time to implement them for my work. As far as I know, I'm the only
one who makes extensive use of sqlt-diff; let me know if I can be of any
help. My only concern at the moment is that I may be making some changes
around this for Oracle over the next couple of days important for my
work and I would rather get those in and working before doing any major
overhauls.

> I also keep getting somewhat irritated by mysqls timestamp=20
> behaviour leaking everywhere.. For example when parsing DB2=20
> or SQLite with timestamp fields, into SQLite, I get magicly=20
> created triggers that I don't need.=20
> Either the mysql parser should create this triggr itself, or=20
> SQLite should at least check which parser it is producing=20
> from before creating that trigger. Unless anyone has=20
> objections, Ill start with making SQLite check the Parser..=20
> (Although that N to N way of doing things is already somewhat
> insane..)

Can't help you with this.

Chris