It has been identified on the devel mailing list that using non-numeric, non-constant, machine-readable node type names as reference keys is a bad idea. We need to introduce numeric DB-generated node type IDs to fix this problem.

Comments

pwolanin’s picture

pwolanin commented

Someone on the devel list suggested "ntid" as the column name- can you consider something longer- like "ntype_id" or "type_id"? I think this would make for more readable code, and ease the conversion from 4.7.

Jaza’s picture

Jaza commented

I suggested ntid. I think it is an appropriate field name, as it is consistent with the other DB field names in core, which are also short and a bit "cryptic" (e.g. nid, cid, tid, uid). I don't particularly like "ntype_id" or "type_id" - they're a bit long. Also, "ntid" is reasonably self-explanatory, especially for developers who will be working with it for hours on end.

pwolanin’s picture

pwolanin commented

Thinking about this more, this seems like a bad idea. Are the ntid values going to be assigned sequentially? That would seem to make it very hard to write hook_form alter, hoook_nodeapi, etc. implementations that are not site-specific, since on my site the "book" type may have ntid == 5, while on your site, maybe ntid == 7, right!?

bdragon’s picture

bdragon commented
Version: x.y.z » 7.x-dev

Bumping to 7.x for further discussion or possibly just dropping the idea...

pwolanin’s picture

pwolanin commented

I suggest "won't fix"

pwolanin’s picture

pwolanin commented
Status: Active » Closed (won't fix)