[development] node types should not be changeable, operations
need hooks
Darrel O'Pry
dopry at thing.net
Thu Aug 24 04:54:26 UTC 2006
On Thu, 2006-08-24 at 14:39 +1000, Jeremy Epstein wrote:
> 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.
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 ...
More information about the development
mailing list