Re: Re: drop table <name> cascade|restrict
| From: | Daniel Convissor | 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