Bummed, this starts adding "junk" to your database straight away.
It really shouldn't add anything to your node table without asking first. Per node rabbit hole actions seems less likely to be used than content type.
The "301" placed in every node table record by default seems pretty silly.

While it's noble to avoid adding yet-another-table for this module, I'm a little off put by adding three fields to the node table when I actually need none.

After saving two nodes (with no Rabbit node settings, and content types left as default behavior as well). I already have useless data in my node table...

mysql> select nid,rabbit_hole_action,rabbit_hole_redirect,rabbit_hole_redirect_response from node where rabbit_hole_action IS NOT NULL;
+-----+--------------------+----------------------+-------------------------------+
| nid | rabbit_hole_action | rabbit_hole_redirect | rabbit_hole_redirect_response |
+-----+--------------------+----------------------+-------------------------------+
|   2 |                 -1 |                      |                           301 |
|   9 |                 -1 |                      |                           301 |
+-----+--------------------+----------------------+-------------------------------+

Comments

doublejosh’s picture

doublejosh commented
Title: Reduce/remove per node record cruft » Reduce/remove per-node data cruft

Don't mean to be negative but Internal Nodes implements this. Feeling like these modules really need to merge.
http://drupal.org/node/1440608#comment-5884322

olofbokedal’s picture

olofbokedal commented

I can see the point in being able to override the settings per node, and this would obviously need some kind of storage. I believe this could be achieved in three different ways:

  1. Adding an extra table
  2. Store the settings as variables
  3. Add columns to the node table

Adding an extra table seems unnecessary, and storing the settings as variables would mean extra work. But if the settings are stored in the node table, the data will load automatically every time a node is loaded from the database, and the settings will get saved automatically. And I can't really see the harm in adding extra columns, as this is supported in core, and by the fact that the settings are directly connected to a node.

That's the reason why I choose the third option.

I'll leave this issue open in case you or anyone else are able to convince me =)

As for Internal Nodes, I'll discuss it in #1440608: Duplicate module.

olofbokedal’s picture

olofbokedal commented
Status: Active » Closed (won't fix)

Closing this issue. Feel free to open it again if anyone has any additional comments regarding the additional table columns.