On 6/3/07, <b class="gmail_sendername">David Strauss</b> <<a href="mailto:david@fourkitchens.com">david@fourkitchens.com</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Assuming the foreign keys patch to the schema API makes it in, there are<br>four ways we can approach foreign keys in Drupal 6.<br><br>1. Don't use them at all. Just provide the schema API for contrib<br>modules with higher database requirements than core.
</blockquote><div><br>This is the path of least resistance, but Dries said that he would consider<br>referential integrity stuff, so we should try.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2. Configure foreign keys as RESTRICT on delete. This will have no<br>effect on MyISAM, but it will improve code quality because operations<br>creating inconsistency would fail. Such operations would then be<br>rewritten to manipulate the database in a consistent way.
</blockquote><div><br>This seems the most sensible given the state of affairs (MyISAM, ...etc.).<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
3. Configure foreign keys as CASCADE on delete and have extra PHP run<br>whenever a query manipulates a database using MyISAM. Basically,<br>whenever a DELETE query gets sent to a MyISAM system, we would convert<br>it to a SELECT query to identify the rows that would be deleted. Then,
<br>we would delete the records attached with foreign keys. Finally, we<br>would run the original DELETE query. This would have to be recursive.</blockquote><div><br>This is moving the database layer work into application code, which is not
<br>a good thing.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">4. Configure foreign keys as CASCADE on delete and have modules
<br>conditionally run queries in their deletion hooks depending on the<br>storage engine. If a module doesn't check the storage engine type, the<br>DELETE it runs would simply be redundant.</blockquote><div><br>Same as my comment on #3.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Personally, I think #2 would be a nice first step in Drupal 6. It would<br>at least force us to clean up the database interaction so #3 or #4 could
<br>be seamlessly added later.<br></blockquote></div><br>Agreed.<br>-- <br><a href="http://2bits.com">2bits.com</a><br><a href="http://2bits.com">http://2bits.com</a><br>Drupal development, customization and consulting.