Sluggable and inheritance

First, inheritance is great feature, thanks doctrine team.

But I have this problem too.

I have identified, the problem is related to class: "Doctrine_Template_Listener_Sluggable", to method: getUniqueSlug($record, $slugFromFields). In mentioned method, table is retrieved from $record ($record->getTable()), but record could be inherited class, so query result on the table is limited only to records of the inherited class. But there could be already rows of other inherited classes with same slug in the database.

Fast hack to solve it, works for me:

• Added option variable to behaviour "table"
• Replaced all calls $record->getTable() as Doctrine::getTable($this->_options['table'])

Thanks for the solution. I do not like the idea of patching the core framework, but it's just how we will have to deal with it. I hope someone will comment on this bugreport so that I'll be informed when the issue is fixed.

The point of sluggable with column aggregation inheritance is to have a unique identifier to make a common interface for all entitis. Like /events/:slug where the presentation is dependent on the modell.
Ofcourse I could have set up one route for every child class, but that will make more code for configuration, whitch is a pain to maintain.

Can anyone provide a patch for the change so I can see everything clearly? Thanks, Jon

Here is a simple patch implementing the changes Jan Míšek proposed. (as far as I understod them)

To make the solution better, it would be nice if the Behaviour somhow found out that it was a child class (without requirering me to specify the parent ) and made sure that it made a slug unique across all subclases, unless the unique by setting spesified the type column. I'm realy glad I had a lot of data to import from a previous site, so that I discovered this bug. I use column aggregation inheritance to make the code for presenting different events in a different way simple. But every event sholud be accessable trough the same route mysite.com/events/:slug.

I hope this patch and test cases solves more than my problems.

Updated the patch a little, so that it does not try to instanciate an abstract class as doctrine generates them.

I was walking up the inheritance tree and tried to instanciate the class right under DoctrineRecord unfortunatly in symfony there is many layers of abstract classes before you find the base class. Now the plugin walks back to the highes not abstract class

Thanks for the issue and patch.

This fix breaks my system.

@see: http://groups.google.com/group/doctrine-dev/browse_thread/thread/8028e51d5bde27eb

Hmm.. I'm sory that my ugly fix to remove the 'where type = $type' part of the query to find existing slugs that might cause a colission with the proposed slug.

Does anyone have a better idea on how to ask for all slugs in the same model? I had a pretty hard time traversing the inheritance tree to find the right parent class that were not abstract. I see that something similar has been done about soft delete, so that a new record would not get the same slug as a record marked as deleted, but not removed from the databse.

Here's an improved patch with a better algorithm to find the column aggregation inhertiance base class:

http://trac.ullright.org/browser/trunk/plugins/ullCorePlugin/patch/Sluggable.patch?rev=3067

This fixes my problem (see above)