Content class version related problems (?)

Saturday 28 June 2008 12:49:19 pm

Hi there,

I've just ran into a problem with one of my 4.0.0 installations. It's a development installation, so no real loss, but some weird things happening. Here's the background:

The installation behaved well (including both object and class editing/modification operations). Then, after extending one of the classes with a new attribute, when trying to store the content class, a transaction failed (I will get back to the details later). Re-sending POST request (F5 in the browser) worked, though, and it seemed like that content class was successfully updated. And that's when strange things started to take place. The recently added attribute was not there, it was not stored, nor seen by the templates. I tried the same operation several times, with no result. Then I removed all of the objects of that class, then I removed that class itself, and started all over again. And it turned out that after putting a new content class together, I wouldn't be able to view it or it would not be on the list of available content classes. That's when I started looking at the db class-related tables. It seems like all the problems occurred for all the classes/attributes with version=1, and from that moment on every new class would get that version ;( Also, which I missed out, all my operations that seemed not to have been stored, were actually stored in class-related tables, just with this version=1.

Something wrong could have been caused by my custom datatypes that are being developed, so I set up a completely new installation/database, checked-out the extensions, and this time it all seems fine, haven't been able to repeat the problem, yet.

As far as the transaction error is concerned: my custom datatype uses its own persistent object class, and the transaction message referenced to that class' db table, that apparently had its unique/primary key duplicated. Now, I'm not sure how that could happen, the only create/insert-like operation ever is performed is for datatype's object initialization:

    function initializeObjectAttribute( $contentObjectAttribute, $currentVersion, $originalContentObjectAttribute )
    {
        // If content cannot produce an object, it most likely does not exist.
        // Try to create a new object.
        $content = $contentObjectAttribute->content();
        if( !is_object( $content ) )
        {
            $contentObjectID = (int)$contentObjectAttribute->ContentObjectID;
            $classAttributeID = (int)$contentObjectAttribute->ContentClassAttributeID;
            (...)
            // Create the object and store it
            $newObject = MyPersistentObject::create( $contentObjectID, $classAttributeID, ... );
            $newObject->store();
        }
    }

The MyPersistentObject::create would create a new record in a db table that has a unique key set on two columns: content_object_id and content_class_attribute_id. By definition, becuase of those values, I don't expect that this attribute could get messed up with another one. The only think that comes to my mind is that this initialization was run twice within a transaction, for some reason...

<b>My questions are:</b>
1) How could it be possible, that a problem with one content class would make all new/future classes "inherit" those problems?
2) What is version=1 in content classes (and related tables), what are they used for? <i>(I haven't noticed version=1 entries in any modified classes in a fully-working installation)</i>
3) Is there something wrong with object initialization in my datatype?

Any help greatly appreciated,
thanks,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu

Friday 04 July 2008 4:38:18 pm

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.

This sounds bad... ;) Seems like "backup your production site before any class modifications" would be a good practice...

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)

Thanks!

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... 

I'd be grateful if you had a minute to see into it. Thanks in advance!

Also, I'll let you know if I find out what I did wrong about the datatypes...

Thanks,
Piotrek

--
Company: mediaSELF Sp. z o.o., http://www.mediaself.pl
eZ references: http://ez.no/partners/worldwide_partners/mediaself
eZ certified developer: http://ez.no/certification/verify/272585
eZ blog: http://ez.ryba.eu