user_load still being called for every node view

Subscribing.

Turned out to be exceptionally easy. #636992: Entity loading needs protection from infinite recursion still makes sense in principle, but this way is cleaner and much more performant for single nodes, as well as much better on memory with lots of comments for the specific case of RDF.

The reason why we had user_load was to give a chance to other module to alter the RDF mappings, but let's leave this option out for performance sake.

If we consider that a regression, we could possibly add hook_rdf_mapping_alter() in a followup - would be a new hook, but no change to existing code.

@catch: since these mappings are cached in entity_info, we decided not to introduce hook_rdf_mapping_alter() because you can do it via hook_entity_info_alter(). The purpose of calling user_load was to be able to alter the mapping on a user basis (as opposed to entity type or bundle basis) so that modules can change the mapping based on some logic (user logged in, etc.).

Ahh I see. In that case I think it's too much of a performance hit to allow for that flexibility. If someone desperately needed it, they could preprocess_username() themselves.

@catch: exactly. agreed.

I definitely like this much better. Committed to HEAD.

I asked catch on IRC if it made sense to revert #636992: Entity loading needs protection from infinite recursion, but he said it's still valuable, since another module might genuinely need to load user objects into nodes (or vice versa, or similar). I think that makes sense, and likely CCK node reference/user reference module are going to need to make use of it. It also makes the entity and field APIs parallel, which is good since they're more than hard enough to learn already. ;)