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.
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.
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.
--Larry Garfield
On 7/12/10 2:53 PM, Brian Fending wrote:
+1 for moshe's .02. Contrib should not, IMO, try to modify that
extensively. Reference point is CCK, which gained simplicity in its
inclusion in Core, but did not assume it. Kosher Law notwithstanding.
On Mon, Jul 12, 2010 at 3:04 PM, Moshe Weitzman <weitz...@tejasa.com
<mailto:weitz...@tejasa.com>> wrote:
my .02 is that such altering is quite reasonable for custom
programming but not so kosher for contrib modules
On Mon, Jul 12, 2010 at 12:19 PM, nan wich <nan_w...@bellsouth.net
<mailto:nan_w...@bellsouth.net>> wrote:
> Is there an official stance on using hook_schema_alter to
add columns to
> core tables? For example, we collect additional data on anonymous
comments
> and want to actually save that data. Rather than creating another
table (and
> subsequent JOINs), I'd just as soon stuff that data into
the comments table,
> where it belongs. Should we ever disable comments (unlikely), we
probably
> wouldn't mind losing that data too.
>
>
> Nancy E. Wichmann, PMP
>
> Injustice anywhere is a threat to justice everywhere. -- Dr.
Martin L. King,
> Jr.
