Flag content module also uses flag_content table

Thanks for this observation, we should probably put some kind of validation in place that'll keep Flag from installing if flag_content has already occupied the table name.

Speaking of table names, I wish 'flag_types' was 'flag_node_types' and 'flag_counts' was 'flag_statistics' (or 'flag_summary').

:-)

On flag_types, this might take on multiple purposes. Like a flag for users might actual store the roles of users that are flaggable. Just a thought.

yes same problem with flag content module, warning with tables names when I installed flag module after flag content !

This needs fixing. People are falling victim to this (#309334: Flags Not Sticking...).

For Drupal 6, there's a hook_requirements hook, and perhaps it even works.

For Drupal 5, that hook exists, but doens't work. So we can use the trick I did in flag_actions_enable() (it's in flag_actions.install()).

Fixed.
http://drupal.org/cvs?commit=142041
http://drupal.org/cvs?commit=142042

(Nate, I didn't wait for a review because the current state is broken anyway, and because I didn't touch existing code so no new harm could have been introduced. Of course, a review is welcome.)

we should probably put some kind of validation in place that'll keep Flag from installing if flag_content has already occupied the table name.

(The code detects "Flag content" installation by checking its "schema version". Not by checking for the existing of its table, because db_table_exists() fails if $db_prefix contains a dot. The detection perhaps could be improved (maybe by using db_column_exists()), by I think it's good enough.)

there's a hook_requirements hook [...]
For Drupal 5, that hook exists, but doens't work.

I filed an issue against Drupal:

#312730: hook_requirements('install') doesn't work for contrib

And I opened a separate issue where people can share their musings about schema changes:

#312734: Schema changes

Thanks mooffie. Looks fine to me.