This should take care of it http://github.com/kla/php-activerecord/commit/0297d8044828c1bcb4a277958c4b8d5c5f614dc7
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?
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?
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.
(1-4/4)
Subject: classify bug
Hello,
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.
s.