Move sticky, promote and user.blocked to flag field types in core.

Just a note to not forget that forum.module makes use of sticky.

Michelle

I don't believe we want to make Drupal slower then it already is. A flag field type in core: why not. Converting sticky and promote to it: no way ;)

So for this not to be a performance drain, we need the field module to hook_schema_alter() the flag columns onto the table for the fieldable entity (so {node}.sticky is owned by flag_field.module's hook_schema() - and when a new field / field instance is created, we do db_add_field() to put it there - and the same for removal.

Then the field module's hook_field_load() hook_field_insert() hook_field_save() handle updating the sticky/promoted etc. statuses on the entity table. There may be another way to do this in field API which completely skips field storage for this stuff, which would save a duplicate insert/update - but I don't know how that's supposed to be done.

The other option would be materialized views in core, but that's not in CVS yet so I don't have high hopes.

This would be great though - you could rename the core 'flags' to something else, and add extra ones very easily, and it'd allow for things like a 'featured' column for users via the CCK/Field UI.

Forum queries wouldn't need to change - but we'd have to either prevent the 'sticky' flag from being removed altogether, or somehow integrate the flag field and forum module to sync up (which seems impossible without Views, so probably forcing sticky/promoted etc. to always exist is the best bet for now - even if you can rename them / remove them from the UI).

Also $node->status any number of things that other modules add.

DamZ pointed out in irc we need indexes as well.

So would need to be db_add_field() and db_add_index() (and keep any composite indexes for the 'core' flags).

one again, flogging an issue I created, but #470580: Allow multiple content types for user blogs would benefit from such a thing (and also has something that can probably easily be expanded into a simple flag module).

For that issue, I was dissuaded to add more columns to the node table, but I am not really even a developler, so people who know better will know better.

We can't use foreign keys in core, because MyISAM doesn't support them, and we need to add conditions on that other table, not just load it into the node object, so there's a real performance impact there. So I think if we have a generic way to add these flags to the node table via the field, then your blog patch could add a 'blog' field instance as a flag, and that would work (and this could be defined per content type, which bangpound's use case would allow for) - also you'd only get the extra field if blog.module was enabled - so sites without that need wouldn't suffer the extra column and index to maintain.

Having used flag module in contrib with views, I can confirm the queries you end up generating can be very, very ugly indeed, so I'm not sure why Crell thinks it's not a problem.

Note that MySQL can not index across tables so if you have a big table you already denormalize anyways. I do not really care where I pull the flags out from, whether it's node or something else, I need to denormalize from several tables anyways.

hook_field_storage_pre_*() hooks can be used to bypass regular storage. So technically having fields 'status', 'sticky' etc... stored in {node} is possible.

Such a move would notably mean that
- $node->status becomes $node->status[0]['value']
- those flags become revisioned [edit: er, ok, probably not if stored on {node}]

I'm not sure I see what this would really buy us, though...

re Josh Waihi #12: "I was gonna write up a patch but field.api.inc has too many TODOs in it to be able to figure out how to implement this"
heh, I cannot leave that unanswered ;-). Working on the missing doc bits, stay tuned.

patch for Field type API docs in #528182: Field type API docs :-p

Feature -> 8.1.

This thread seems to have lost momentum, and much has changed in the interim. Marking postponed for now.

All three of these are boolean base fields now, I think that is the closest to a "flag" field that we have in core - I suggest this can be closed as outdated.

Marking duplicate of #29338: Hide Promoted/Sticky fields by default in Form display.