New Approach to Content Types.

Events happening in the community are now at Drupal community events on www.drupal.org.
mgparisi's picture

I have been writing up a white paper on how Drupal could work, but wanted to submit an initial and important first step. I know allot of people see comments as nodes being a major issue. Many want it, while others site potential problems with performance. Without comments as Nodes we have no code uniformity making any CCK features and Views features needing exceptions based on if its a node or if its a comment.

What if I could tell you that I could make comments as nodes and not effect performance? What if I could tell you that on very large sites (like Drupal) I could actually enhance performance across the site? The solution is simple. What if we gave every content type its own table? The current "comment" system would simply be a content type that uses the new unified content structure. Since the default comments content type would be "comments" it would have its own table, as would stories, pages, books, etc.

The second step of this (but not absolutely needed) is to include views into core, and be able to attach views to content types. An example of a Content Type "Article" would be a content type with a Title, Body, and lastly a "comments" view. In addition we would have a content type called "comment" (notice the singularity).

Comments

Have you looked at Drupal 7

Scott Reynolds's picture

Have you looked at Drupal 7 Field API? I believe what you are purposing is similar to whats in D7 (minus the View part which I figure is the reason you posted it in the Views Developers group....)

Thanks

mgparisi's picture

The field API is very good, and is definitely a step in the right direction. It actually handles allot of situations that I have seen but have not been able to come up with a solution for. It is actually a valuable resource. I must Admit, that I do not know much of D7. I am so busy working on projects that I have not been able to code.

The concept expands beyond the issue of adding fields to comments. Its about about working towards a unified data and code structure. There is many reasons for this, Some of these reasons will become apparent as more topics emerge.

Examples:

  1. On Drupal.org, the document team rolls comments into the document. After we add the comment to the Document, our only option is to Delete the comments. Now there is discussion about unpublishing nodes over deletion of nodes. There is no way to un-publish a comment.
  2. Eventually even the API section of Drupal will have "comments". However, what we might want is "examples". Essentially comments but that are customized for adding code to the database. Now we may also want to include the revision system on these examples.
  3. On YouTube a user can "comment" with video. The comment system is not based on a text or description. What the comment based system is built on is a reference from a video content type to another video content type. (I will address adding a relationship system to views and CCK in the future)

Essentially by unifying nodes and comments you get all of the features of Nodes within comments.

Now there is the issue of Speed. In my proposal, on a site like Drupal.org, Forum Posts, Book Pages (Documents), and the many other pages are all within one table. However in my model, Books, Forums, Events each get there own table (along with comments). On a site like Drupal.Org, the speed on inserting new nodes will very noticeable, and the speed on a select will also be reduced.

Node comment

michelle's picture

Aside from the table per content type, which I suspect wouldn't work very well, most of what you're saying sounds like nodecomment.

Also: "There is no way to un-publish a comment." Sure there is. You just change the radio button from published to not published.

Michelle


See my Drupal articles and tutorials or come check out the Coulee Region

Code Unification

mgparisi's picture

I would like to know why you don't think each content type should have its own table, when it already does?

What I purpose is already widely talked about, the demise of the "node". But I want to push this idea that with the demise of the "node" can also include the demise of the "comment". That the ideas being talked about should also include a unification of code between all comments and nodes. What I purpose is that the Internet is no longer a Subject/Title and a Body/Comment. That the new web requires complex relationships. Many to Many, 1 to Many, 1 to 1 or Parent to Child. The new web is also not text, but sound, video, images, and applications. The new web is no longer text and response, but developing customized relationships between users, data and code.

Drupal is a content management system, not a document management system. Drupal is not a blogging tool or a forum. Drupal is much more then that. Its scope is much wider, and people hanging on ideas that date back to forums and blogs (articles) is frustrating.

Anyone stating that they have THE answer is wrong. Database and Application performance is based on the usage. One size never fits all. A hundred thousand rows is not a large database table. Right now my node table has 2,098 records and 4,870 comments. Why is a comment not a content type? Why must the majority of people who have less then a few hundred rows be limited with the default comment system.

The failure to recognize comments as a content type with-in core, and instead use a separate module to perform the same results hurts the majority of Drupalers. Those that have the traffic that would cause database degradation has a serous business that would have to think about a custom solution. Drupal could never power MySpace, YouTube, or the major infrastructures that not only require data to be seen, but also to be regularly inputted.

The main issue here is a standardized code base

With a standardized code base the core developers could focus their efforts to improve cache and other resources that promise a great improvement in performance. Without a standardized code base, comments and nodes must both be handled.

With content types being handled independently, database optimization can be performed on a case by content type case. That's not to mention the number of modules that were wrote for Nodes that can now be tailored with the base notion that all comments are a content type. Requiring a 3rd party module excludes developers and themers from designing for the masses.

I believe that with a standard code base, Drupal Development Progress will be accelerated, the API will be smaller, and the ability to focus on more complex and/or more performance based measures over all will result in a more powerfull, faster, stronger system.

One thing this post has done, is allowed me to recognize and better address the topic in greater detail, with a better focus on the core issues.

@mgparisi, you're not

Flying Drupalist's picture

@mgparisi, you're not putting this in the correct context. It's not a failure to recognize comments as a content type, it's the necessity of needing a more lightweight solution to comments than nodes in the older versions of drupal. But since Drupal 7 has such vast improvements to nodes, it makes sense that 'comments' should be a CT.

So this probably falls under a feature request that hasn't been done yet, rather than an OMG you're doing this all wrong!

@Flying Drupalist

mgparisi's picture

Can you point out any statements that I made that seem to convey the "OMG you're doing this all wrong!" feeling that you get? That is not my intention and I would like the opportunity to correct any poorly written statements.

Views Developers

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: