#20 Invalid type_nodetype on node throws 500

[Jay Bonci]

If a type_nodetype on a node get's corrupted (or the
parent type gets whacked), we throw a 500 error when
trying to view the node. This makes it really hard to
clean up after it (with a nuke or what not, just to
get it out of the main node table).

In an ideal world, we should simply resort to the
displaytype and permissions for that of an object of
type [node]. This would be the safest best (as we
wouldn't need to assume that the type is there for
anything else). It would also allow system
maintainers to whack the node enough to clean it up
(or edit it's type or whatever other thing they should
choose to do to the now dead object).

This is similar to the previous issue of ecore tossing
a 500 when an invalid displaytype is given, but it has
more to do with the types than does anything else.

Low priority of course.

--jay

[chromatic]

Logged In: YES
user_id=2274

This may be fixed with the patch that makes nodes actually
inherit from their parents. Can you confirm it on the
preloading branch?

[chromatic]

Logged In: YES
user_id=2274

Here's a patch (against the preloading branch, but it should
backport very easily) that fixes it for me. If a node has
an invalid type, it's logged and not loaded. This displays
a 'not found' page to the user instead of crashing.

[chromatic]

preliminary patch for this issue

[paul_the_nomad]

Logged In: YES
user_id=89398

Hello all,

This is a problem that looks simple, but is in fact
complicated, because it throws up all sorts of ancillary issues.

JayBonci's point is that a node with a corrupt type won't be
displayed on the web interface and therefore can't be nuked.
So, what is the solution? Like all intractable problems
this one becomes easier to understand if we break it up
little bits:

1) what is a corrupt nodetype? One that doesn't exist? One
that isn't of type 'nodetype'? One that somehow won't load
for some other reason, e.g. db corruption?

2) Should all 'corrupt' nodetypes be handled the same way? A
nodetype that doesn't exist is different from a "nodetype"
that actually is not a nodetype but a different type.

3) If a node with a corrupt 'nodetype' is deleted, then the
db might have tables and/or rows that don't belong to any
node. In other words the db might need cleaning up. A set
of db admin tools might be useful here which look for tables
and rows that aren't used by any nodes.

4) The obvious place to deal with this issue is in
Everything::Node::assignType. The question is how? But it
comes down to:

5)How should ebase handle exceptions? For example should
there be an Everything::Exception module that handles things
like corrupt types plus a whole other range of things?
Should ebase use try..catch...throw blocks for this? I
think useful error handling techniques that could be used
are in the mod_perl ref here:
http://perl.apache.org/docs/general/perl_reference/perl_reference.html#Alternative_Exception_Handling_Techniques

That is using eval blocks plus an exception class (e.g.
'Everything::Exception') would be the best way forward.

Views?