On Thu, 2006-08-24 at 14:39 +1000, Jeremy Epstein wrote:
On 8/24/06, Neil Drumm <drumm@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@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.
so thats what orig type is for... I was wondering about that... I may need to update the cck patch @ http://drupal.org/node/80335 ...