<html><head><style type="text/css"><!-- DIV {margin:0px;} --></style></head><body><div style="font-family:arial, helvetica, sans-serif;font-size:12pt"><DIV></DIV>
<DIV>First, in case I didn't say it, this is for an internal customer module, period. I would not be thinking of this for a contributed module, much as I would like to in some cases (especially pre-D7 taxonomy).</DIV>
<DIV> </DIV>
<DIV>I don't fear JOINs. In this case, it just seems like the best place to put this data is with the other stuff to wchich it belongs. In this case, that is with the comment row. As it turns out, it doesn't make much difference because the comment module doesn't use drupal_write_record, so I would need a hook_comment to add those fields any way. What a pain!<BR></DIV>
<P><FONT face="bookman old style, new york, times, serif" color=#ff007f size=4><EM><STRONG>Nancy E. Wichmann, PMP</STRONG></EM></FONT></P>
<P><FONT face="arial, helvetica, sans-serif">Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.</FONT></P>
<DIV><BR></DIV>
<DIV style="FONT-SIZE: 12pt; FONT-FAMILY: arial, helvetica, sans-serif"><BR>
<DIV style="FONT-SIZE: 10pt; FONT-FAMILY: arial, helvetica, sans-serif"><FONT face=Tahoma size=2>
<HR SIZE=1>
<B><SPAN style="FONT-WEIGHT: bold">From:</SPAN></B> "larry@garfieldtech.com" <larry@garfieldtech.com><BR><B><SPAN style="FONT-WEIGHT: bold">To:</SPAN></B> development@drupal.org<BR><B><SPAN style="FONT-WEIGHT: bold">Sent:</SPAN></B> Mon, July 12, 2010 4:47:59 PM<BR><B><SPAN style="FONT-WEIGHT: bold">Subject:</SPAN></B> Re: [development] (no subject)<BR></FONT><BR>I generally warn people away from modifying another module's tables (core being a collection of modules). The potential for collision, confusion, and stuff randomly disappearing on you is too great.<BR><BR>If you have a one-off where you know what your situation is, then you can sometimes get away with it. A contrib module on d.o that starts messing with the user table, for instance, is a code smell that I want to stay far away from it.<BR><BR>JOINs, especially on indexed integer fields (like nid, uid, etc.) are really really fast. SQL is designed to make them fast.
Don't fear the join.<BR><BR>--Larry Garfield<BR><BR>On 7/12/10 2:53 PM, Brian Fending wrote:<BR>> +1 for moshe's .02. Contrib should not, IMO, try to modify that<BR>> extensively. Reference point is CCK, which gained simplicity in its<BR>> inclusion in Core, but did not assume it. Kosher Law notwithstanding.<BR>> <BR>> <BR>> On Mon, Jul 12, 2010 at 3:04 PM, Moshe Weitzman <<A href="mailto:weitzman@tejasa.com" ymailto="mailto:weitzman@tejasa.com">weitzman@tejasa.com</A><BR>> <mailto:<A href="mailto:weitzman@tejasa.com" ymailto="mailto:weitzman@tejasa.com">weitzman@tejasa.com</A>>> wrote:<BR>> <BR>> my .02 is that such altering is quite reasonable for custom<BR>> programming but not so kosher for contrib modules<BR>> <BR>> On Mon, Jul 12, 2010 at 12:19 PM, nan wich <<A href="mailto:nan_wich@bellsouth.net"
ymailto="mailto:nan_wich@bellsouth.net">nan_wich@bellsouth.net</A><BR>> <mailto:<A href="mailto:nan_wich@bellsouth.net" ymailto="mailto:nan_wich@bellsouth.net">nan_wich@bellsouth.net</A>>> wrote:<BR>> > Is there an official stance on using hook_schema_alter to<BR>> add columns to<BR>> > core tables? For example, we collect additional data on anonymous<BR>> comments<BR>> > and want to actually save that data. Rather than creating another<BR>> table (and<BR>> > subsequent JOINs), I'd just as soon stuff that data into<BR>> the comments table,<BR>> > where it belongs. Should we ever disable comments (unlikely), we<BR>> probably<BR>> > wouldn't mind losing that data too.<BR>>
><BR>> ><BR>> > Nancy E. Wichmann, PMP<BR>> ><BR>> > Injustice anywhere is a threat to justice everywhere. -- Dr.<BR>> Martin L. King,<BR>> > Jr.<BR>> <BR>> <BR></DIV></DIV></div></body></html>