Szymon W Wed Jun 30 14:45:47 -0400 2010

Subject: classify bug


I found a bug in the AbstractRelationship class. There is a method
set_inferred_class_name() which does the "classify" routine with the singularize parameter set to true.
But the Utils::singularize method returns a wrong result if the singular class name looks like a plural one, particularly the word "status" becomes "statu".

To reproduce please create models: Order and OrderStatus. Then set the association in the Order class:
static $belongs_to = array(array('order_status'));

You'll get the error info that OrderStatu.php cannot be found.


Kien La Sun Jul 04 16:51:04 -0400 2010
Szymon W Wed Jul 07 17:14:42 -0400 2010

well, almost works fine, however still I don't get why the singularize is fired for the cases where a singular noun is already provided. Now, after this and the next one commit (with '/(us|os)$/i'), ProductPhotos cannot be singularized correctly :(.

How about overriding set_inferred_class_name() in those relationships where the singular noun should be provided (BelongsTo, HasOne), to explicitly set singularize to false, by passing proper classify() method parameter?

Kien La Fri Jul 09 19:51:38 -0400 2010

Good suggestion about only singularizing on HasMany. I've made that change and it should also handle ProductPhotos correctly now. Mind grabbing the latest version off github and seeing if it fixes your problems?

Szymon W Sat Jul 10 03:51:00 -0400 2010

Thanks. It seems everything is ok now. One thing I would suggest is to use polymorphism instead of checking if the current object is a HasMany instance. I mean you could have a general implementation of set_inferred_class_name() in the abstract super class, overrided directly in the HasMany class, to get the right behavior (singularizing). In this way, you would use the oo features of the language instead of manual type checking.
I have a strong Java background so the polimorphic way looks much better for me.