Re: Re: drop table <name> cascade|restrict

From: Date: Tue, 02 Nov 2004 18:18:23 +0000
Subject: Re: Re: drop table <name> cascade|restrict
References: 1 2  Groups: php.pear.dev 
Request: Send a blank email to pear-dev+get-34196@lists.php.net to get a copy of this message
Hi Frank, Lukas, et al: On Mon, Nov 01, 2004 at 09:21:46PM +0100, Lukas Smith wrote: > > I asked Frank Kromann about this and this is his reply: > > "Setting the default to 'restrict' will give an error when you drop a > table with forign key references from other tables, and having the > driver add stuff to the SQL statements also sounds a bit wrong to me. > If you had a dropTable() method it would be easy to have an extra > parameter to handle the restrict|cascade problem." I figured RESTRICT would be the better default because it would avoid inadvertent loss of data and in "SQL-99 Complete, Really," Pelzer and Gulutzan said it's more widely accepted. But, I'm not wed to it. CASCADE is definitely easier. It's not a big deal to me either way. While tweaking queries before execution is kind of funny, that's how DB already accomplishes several goals. That's the whole purpose of modifyQuery() and modifyLimitQuery(). Similarly, the fbsql driver appends semicolon to the end of the query. Adding a dropTable() method would eliminate the possibility to simply move an existing application to fbsql from another driver. Another approach is to create a method that can be added in the middle of a query string that inserts the RESTRICT/CASCADE as needed: $db->query("DROP TABLE $table " . $p->getDropRestrict()) But that also has the downside the dropTable() idea has. Your further thougts will be appreciated, --Dan -- T H E A N A L Y S I S A N D S O L U T I O N S C O M P A N Y data intensive web and database programming http://www.AnalysisAndSolutions.com/ 4015 7th Ave #4, Brooklyn NY 11232 v: 718-854-0335 f: 718-854-0409

« previous php.pear.dev (#34196) next »