[development] (no subject)

[larry at garfieldtech.com]

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 <weitzman at tejasa.com
> <mailto:weitzman at 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_wich at bellsouth.net
>     <mailto:nan_wich at 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.
>
>