ClassName Enum problems

[Michael Gall]

I continuously have this problem when I'm developing and it doesn't matter because I normally just blow the database away and start again, but today I've had it happen on a livish site and it's giving not making me happy. The problem is....

In the parent Table of a DataObject the ClassName is stored in an Enum. That's fine, it helps with data integrity and so forth but a problem occurs if for some reason one of the subclasses is removed and a db/build is performed. The enum is changed to have the subclass removed, and the table ends up with an empty ClassName for all the old class types.

I believe using an Enum to store that column is a mistake, and that we should use a Varchar and let the DataObject implementation take care of itself in regards to missing classes or incorrect inheritance.

What do other people think? Has anyone had this problem before?


--

http://wakeless.net

[Sigurd Magnusson]

Would it not then be better for db/build to only remove the classname
once it determines an old value is no longer used in that column?
Thereby keeping data integrity?

Sig

[Michael Gall]

Yeah... it derives what should be in the column from the subclasses found in the application. We would need to check the table definition first I suppose, pull the definition of the Enum first then comparing and adding or removing any values would work.

[Sam Minnee]

The main reason we used Enum was for performance.

Since we do some pretty heavy filtering via the ClassName field ( a
big old IN ('X','Y'Z) filter on pretty much every single query),
performance of that field is a major issue.

Another solution would be to only remove options from the Enum if
there wasn't any existing database content that used that Enum value.
This could potentially apply to all enums, not just ClassName.

The workflow would then be:
* Run db/build
* Correct your data
* Run db/build again to remove the old enum values.

[nor...@silverstripe.com]

How about we make our db/build to change ClassName of every record
which represent the old subclass to its parent class name, ie, before
doing anything, db/build knows which subclass will be removed in this
build, and then go to the very root table to change all records which
mark as that subclass to be its parent class, and then safely remove
the subclass table.
And yes, we do have the same problem before. But we solve the problem
by fixing those broken data by hand as Sam suggested.

[Michael Gall]

Changing to the parent class doesn't work because you still lose the data that was in the database. Usually I would be able to fix this by doing Update ParentClass set ClassName = 'ChildClass' where id in (select id from ChildClass), but in this most recent occurence I had classes that didn't have their own tables. So it all went up in smoke.

I don't mind having to fix it by hand, but the default should definitely save the data, rather than delete it.

--

http://wakeless.net