Since the current node example is quite extensively in the D7 mode, but it's easy enough (and perhaps faster) to implement a node type with the traditional technique, we should add the traditional technique in there as well. See #508342-20: D7 Node example demonstrating fields.
Comments
Comment #1
cyberswat commentedThanks for opening this issue. I didn't want to re-open the issue that you reference but I think that the correct response to tanoshimi was that the storage of the fields is pluggable in d7. This means that you can use hook_schema() to define your own tables like you would in d6 and then in hook_entity_info() you can set the 'base table' => your_table_name.
This opens the door for not only addressing all of his concerns about performance and indexing but also allows you to use alternative storage like mongodb.
I'm not entirely convinced that a second module that shows the old way of doing it is a good solution. I suggest we either replicate what was done in node_example() but use hook_schema() to define it's storage or simply add comments to the existing node_example.module ... my preference is for the comments simply because it's a bit more of an advanced subject that might confuse new developers using the example module to learn.
Comment #4
rfayWe actually have a D6-style node example in simpletest_example.
I'm just going to mark this fixed.
Comment #6
rogueturnip commentedOne that I've discovered in playing with this node example is that as soon as you want to move beyond a very simple node (add ajax, states, etc) the Fields method really gets challenging.
Having the fields in the core is great but I think there are still very valid cases for using a custom schema with hook_load and hook_save type operations.
Comment #7
rfay@rogueturnip, did the nodeapi_example help you at all? We tried to move that kind of thing over there.
Doing it D6-style is basically the same as it was in 6 (except for the splitting out of the APIs). But maybe nodeapi_example will help there.