[Dbix-class] admin functions for the storage object?

[Ash Berlin]

Matt S Trout wrote:
> On Fri, May 04, 2007 at 08:48:22PM +0100, Jess Robinson wrote:
>> On Fri, 4 May 2007, John Napiorkowski wrote:
>>
>>> Hi,
>>>
>>> Not sure if this is something other people care about but I end up have to 
>>> write some
>>> driver specific code for stuff like dis/enabling FK constraints and so 
>>> forth to make it
>>> easier to deploy tables and preload data.  I know this doesn't effect all 
>>> databases
>>> and each database has it's own way to deal with this.  So I was wondering 
>>> if this might
>>> be a useful thing to add to the storage class.  I would add some methods 
>>> to do stuff
>>> like
>>>
>>> -- dis/enable FK support
>>> -- dis/enable triggers
>> This is/should be already done by SQL::Translator::Producer::MySQL (turns 
>> off foreign key constraints), if you'd like to patch sql for the rest, 
>> I'll commit the patches.
> 
> The problem is that it's also important for bulk data-loading, which is kinda
> on the boundary between DDL and DML stuff. Really, I think we probably need
> to accept that there are some things that mix across boundaries and in the
> absence of a unified SQLT/SQLA type project the storage object is probably
> the best place for it.
> 
> Plus, correctly formulated DDL shouldn't actually require FK constraints to
> be turned off so I'd rather see a patch to SQLT to re-order things correctly
> and not do that in there at all!

Sadly, this is not the case for MySQL w/InnoDB - there are some 
situations where InnoDB will flat out refuse to alter a table with 
constraints on it (I forget the exact pattern needed, but i know it 
exists.) But for create, yes this is possible.

Also what about loops in constraints? (A -> B -> C -> A, or just A -> A 
for that matter)

And I'm fairly sure I made SQLT::Producer::MySQL disable the key checks 
anyways..... could be wrong tho, I have been before.

-ash