While comments currently are expandable it's not a good thing really -- those decorated comments should be nodes, we currently have a hook comment which is almost as rich as nodeapi just not quite and having two almost same but not really same ways to do things are quite ugly. This is already recognized by other comments-as-nodes movements. Normal comments and aggregator items should be small nonfieldable nonexpandable fast pieces that have an author (which can be anonymous), subject, body, link. Still comment and aggregator item would be a different table with additional columns like GUID or thread but these do not change the matter that a whole page of items can be retrieved with one single query and thrown out rather quick. If you really want to add more displayable things then hook_schema_alter, hook_query_alter and custom theming is your friend.

Comments

chx’s picture

On second thought, after a discussion with Moshe *maybe* we keep comment API but still, using the same small and quick API for aggregator items and comments makes some sense to me.

catch’s picture

With the current state of hook_comment_load() - having modules enabled which implement the hook is likely to slow things down to node levels, since there's no multiple load for comments (and I don't plan to write one). Also having comment_upload() and all these other modules which have to reinvent the wheel is evil. Making them fieldable would introduce the same issues.

At the same time, when benchmarking raw nodes vs. raw comments, especially at high numbers per page, - comments beat nodes in a big way at the moment with anything over 10-20 per page. So blog sites which need a very lightweight solution and won't be trying to do anything else would get an unacceptable penalty, unless we can radically speed up nodes in the meanwhile.

So, stripping comments down to an extremely lightweight item (and aggregator items are a good fit for this model too) makes a lot of sense to me, and chx suggested allowing for comments-as-nodes in core as an option, to 1. provide an upgrade path for those using hook_comment() modules 2. save making comments themselves heavier to accommodate these use cases.

Michelle’s picture

Here's a discussion we were having on g.d.o about micronodes last month that may be relevant: http://groups.drupal.org/node/17847#comment-61153

Michelle

SeanBannister’s picture

Michelle: are you working on Drupal 7 forums? I heard there was talk of forum comments as nodes?

There's definitely a need for adding CCK fields to comments but I don't think this should penalize those who don't need this functionality. I would support a comments as nodes option in core so users have the ability to turn this feature on if needed.

Michelle’s picture

@SeanBannister: It depends on when freeze is. I'm too swamped in contrib to think about core, yet. Once I get 1.0s out of all my modules, I'll have more breathing room. At any rate, our plan was not to make all comments nodes but to specifically make all forum posts nodes. It wouldn't be optional as core forum would be rewritten to use all nodes.

Michelle

chx’s picture

About comment links, I think comment module will provide a basic set of comment links in an array and let preprocess change that if at all necessary. We still can cache the whole rendered chunk per role.

catch’s picture

Comment links proposal sounds good to me.

alex_b’s picture

I like this idea. I'm still wrapping my head around what this could mean for aggregator. I'd like to see more specifically what this API would consist of: basic approach + API functions.

alex_b’s picture

How does this look for a start?

// Create storage for the items that we'd like to store.
drupal_item_create_table('aggregator_item', $schema);
// Insert/update a new item.
drupal_item_save('aggregator_item', $item);
// Delete an item.
drupal_item_delete('aggregator_item', $item);
// Load one or more items.
$items = drupal_item_load('aggregator_item', $ids);
// Destroy item table.
drupal_item_drop_table('aggregator_item');

Every item is going to have at least a column id as primary key. In drupal_item_save() there could be a drupal_alter() before the $item goes to the DB. Otherwise existing schema and query hooks should be sufficient to extend the item API. drupal_item_create_table() would create the database table, store the schema and expose it through hook_schema().

We could use this for comments and for aggregator items - what else?

tstoeckler’s picture

I know this is far from being committed, but with this: #119102: Combo field - group different fields into one, comments could be A FIELD (vs. fieldable). The same could go for aggregator items. Just wanted to crossreference...

catch’s picture

nedjo also has some work on generic load for objects in #365899: API methods for schema-based load and delete operations.

chx’s picture

Good people, what the mythical data API has to do with this? We are loading a bunch of items belonging to an entity, paged. I have no intentions of providing a CRUD API, use drupal_write_record, period. Small, simple etc.

Xano’s picture

Status: Active » Closed (won't fix)

Comments are now entities.