Friday 04 July 2008 6:18:21 am

1) Problems during class editing usually cause corruption in the database affecting all existing classes. I have once experienced the same thing with a custom datatype and each test run to pinpoint the exact problem would require a manual cleanup.

2) Version 1 for content classes and class attributes means those entries are temporary. Stored class definitions have version 0. If you edit a class, the class and the attributes get version 1. When you store the class, version 1 becomes version 0 again. (See the constants in eZContentClass)

3) I have once experienced a similar thing with a custom datatype, but it was a couple of years ago. I'm not at work now where I could access the SVN logs, but I'll try to remember to check this on Monday. Some faint light shines on $currentVersion though... I think that was what you should check on, but I'm not sure...

Hans
http://blog.hansmelis.be

Sunday 06 July 2008 9:57:48 pm

I've found the thing I was looking for in our svn logs. The log message for the commit is: <i>Bugfix: Crash when adding 'xyz' datatype to a class</i>.

The big change in that commit was indeed a check on $currentVersion. Before, the whole code block of that method was surrounded by:

if( $contentObjectAttribute->attribute( 'version' ) > 1 )
{
    ...
}

and was replaced by

if( $contentObjectAttribute->attribute( 'version' ) > 1 && !is_null( $currentVersion ) )
{
    ...
}

So I'd say that $currentVersion can be null when you're adding an attribute to an existing class. And in that case, it's quite likely you don't have a valid (or complete) content object yet.

Hans
http://blog.hansmelis.be