[development] Is it possible to have separate table for different content types in D7

[nan wich]

Blake, I totally agree. When I created my first node module, even the docs you 
mention didn't exist. I had to look at other modules to get an idea of how to do 
it. I even had to do the same with adding fields to Views.

"...unless what they offer is documented, in a manner that others can 
recreate... it may as well not exist" is absolutely true. However, one must also 
realize that one form of documentation may not "fit all." For example, I really 
appreciate all the Views docs that exist now, but most are written way over my 
head - and I am no beginner with Drupal. I fully accept that my failure to grasp 
those docs are my fault, but I have heard many others express the same feeling, 
while, at the same time, I see others just glance at it and turn out perfect 
code right away. Different people learn in different ways. I guess that's why 
there are many books.
 
Nancy
 
Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, Jr.




________________________________
From: Blake Senftner <bsenftner at earthlink.net>
To: development at drupal.org
Sent: Fri, February 11, 2011 10:45:33 AM
Subject: Re: [development] Is it possible to have separate table for different 
content types in D7

Granted, I've not yet dived into the D7 specifics of creating custom content 
types, but I'd like to address a point Nancy makes here: 


Lastly, why? I would think that the overhead of managing multiple tables would 
outweigh any potential gains. I can't even begin to think what you would have to 
do to Views to make it work in your scenario.

I consider it an issue of quality documentation. When I was first learning 
module development, CCK was nice, but I could not figure out how to 
programmatically create or manage CCK fields.  Being unable to programmatically 
create content types with CCK meant that my modules either could not implement 
content types, or I'd have to make them without CCK. There was no quality 
documentation explaining CCK at the time, so via books like "Front End Drupal" 
and "Pro Drupal Module Development" I learned how to create my own tables and 
manage them myself, including the not-difficult-because-it's-documented 
integration of custom fields with Views. (see: 
http://views-help.doc.logrus.com/help/views/api-tables).

I absolutely do not mean to pick on Nancy. I love Drupal. I'm betting my company 
on the Drupal technology stack. But developers have got to realize that unless 
what they offer is documented, in a manner that others can recreate and expand 
on your module's facilities, it may as well not exist. Poor or missing 
documentation leads to poor, incorrect, or missing integration with other 
modules. (Sorry if this sounds like a rant. Trying to figure out things in 
Drupal is a sore spot for me.)

Sincerely,
-Blake
bsenftner at earthlink.net
www.BlakeSenftner.com


On Feb 11, 2011, at 7:16 AM, nan wich wrote:

There are several extra questions to be asked here:
>	1. Define "separate." If one creates a node module that creates content types, 
>then one must manage the extra fields - generally in new (i.e. separated from 
>node & node_revisions) tables created by the module.
>	2. If one is talking about content created by other (e.g. core) modules, then 
>the answer is maybe. Take a look at the sql rewriting hooks or whatever D7 has 
>done to them.
>	3. Lastly, why? I would think that the overhead of managing multiple tables 
>would outweigh any potential gains. I can't even begin to think what you would 
>have to do to Views to make it work in your scenario.
> 
>Nancy
> 
>
>Injustice anywhere is a threat to justice everywhere. -- Dr. Martin L. King, 
Jr.
>
>
>
>
>
________________________________
From: Deva <devendra.in at gmail.com>
>To: development at drupal.org
>Sent: Fri, February 11, 2011 7:59:26 AM
>Subject: [development] Is it possible to have separate table for different 
>content types in D7
>
>Hi All,
>
>Is possible to have separate table for each content type?
>
>Thanks in advance
>
>-- 
>:DJ
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20110211/99279eb4/attachment.html