Taxonomy tables have been renamed in D7. Rename {term_access} and {term_access_defaults} to be consistent, and implement hook_update_N() for these changes.

Comments

David_Rothstein’s picture

I believe I signed up to work on this issue also.

Just to clarify... the renaming you're thinking of is {taxonomy_term_access} and {taxonomy_term_access_defaults}, right?

xjm’s picture

Title: Rename {term_access} and {term_access_defaults} » Update schema for D7

I think {taxonomy_access_term} and {taxonomy_access_default} would be good. That way the table name starts with the module name. (I think the idea before was to make it obvious they shared keys with {term_foo} tables.)

There's a related schema question I'd forgotten: I believe DBTNG supports foreign keys? Should {taxonomy_access_term}.tid and {taxonomy_access_default}.vid be declared as foreign keys from {taxonomy_term_data} and {taxonomy_vocabulary}? The one problem I can see is that we use 0 as the "vid" for global defaults.

Edit: just chatted with pwolanin on IRC about this; I guess the foreign keys are "for documentation purposes only" and don't actually add referential integrity. http://drupal.org/node/146939

David_Rothstein’s picture

Status: Active » Needs review
StatusFileSize
new14.36 KB

OK, glad I asked... yes, that makes more sense. Here's a patch (lightly tested).

I actually wonder if the second one would be better as {taxonomy_access_term_default}? Anyway, it's pretty easy to change via find-replace in the patch file if necessary.

I didn't deal with foreign keys here, since it sounds from your comment like it's not clear if they are 100% used that way. It could be a separate issue.

Oh, and the only places in the module left after this patch that use 'term_access' are the realms in the node access hooks. I guess there might be an argument for renaming those too.

xjm’s picture

xjm’s picture

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.