[development] node types should not be changeable, operations need hooks

[Jeremy Epstein]

On 8/24/06, Neil Drumm <drumm at delocalizedham.com> wrote:
> Database: databases like numeric keys. I think it would be good to
> replace the machine-readable type there with numbers.
>
> PHP code: since there is no exposed UI here (always use the [human
> readable] type name), I think the same numbers might work. This is a bit
> harder with hard-coded node types, since they have a hard-coded name
> that is used. Perhaps the hard-coded name can be recalled and used for
> hook invocation where applicable.

Hard-coded node types is the main reason why we didn't introduce
numeric node type IDs into the pre-CCK patch. A numeric node type ID
is of little value, when you still have to match database node types
with hard-coded node types, based on the original machine-readable
name.

However, I can see that numeric node type IDs (for which, btw, I would
suggest 'ntid' as a DB field name) would indeed make life much easier,
in terms of foreign key references to node types in the database (e.g.
the 'type' field in the 'node', 'vocabulary_node_types', and other
tables). We should definitely investigate bringing them in, despite
the fact that we'll still have to keep 'orig_type', and use that for
linking back to hard-coded module-defined types.

On 8/24/06, Darrel O'Pry <dopry at thing.net> wrote:
> Why not use a sanitized human readable name in places like css and html
> output?  What we're really talking about is user morphable database
> keys, which in my opinion is out right wrong. We don't give end users
> access to change nids? or any other ids do we?

Darrel is right, using non-permanent fields as database keys is
suicide. It's only a matter of time before that causes problems. So
yeah, let's keep allowing users to change the machine-readable type
name, let's keep using 'orig_type' so that DB node types can reference
their hard-coded equivalents, and let's introduce non-changeable
numeric IDs for node types, to be used as reliable primary keys.

I have created an issue for this task:

http://drupal.org/node/80375

Cheers,
Jaza.