Interesting issue with Merb's Controller#resource and DM association

[phatmann]

I discovered an interesting issue with Merb's Controller#resource
today. I posted about this to the merb list, but it seemed relevant
for DM as well. The issue is this:

resource(Company.first, :teams)

works fine but

resource(@team.company, :teams)

fails to find the route.

After some digging, I discovered the problem. To find the route,
#resource uses the object's class name as part of the route key.
Company.first is of class Company, and @team.company is of class
DataMapper::Associations::ManyToOne::Proxy. The interesting thing is
that calling inspect on each of them gives the same results, since
Proxy overrides #kind_of?, so this problem took me a while to find.

I suppose DataMapper::Associations::ManyToOne::Proxy should forward
#class as well, unless there is another solution anyone could propose.
Is there a different method that #resource could be using to turn the
class into a key?

The workaround for getting the right class is:

company = Company.get!(team.company_id)

(Another workaround in Merb is to use named URLs with the #url method
and avoid this problem
entirely, but I want to be consistent and use #resource for all
resource
links.)

My colleague suggested another interesting workaround that Merb could
implement:

class Object
def real_class_name
class.to_s
end
end

class Proxy
def real_class_name
parent.class.to_s
end
end

And then #resource would use real_class_name instead of class_name.

..tony..

[Dan Kubb (dkubb)]

Hi Tony,

> The issue is this:
>
>   resource(Company.first, :teams)
>
> works fine but
>
>   resource(@team.company, :teams)
>
> fails to find the route.

This is actually a known issue that Carl Lerche originally
discovered. It is fixed in edge sam/dm-core as of 3 days ago:
http://is.gd/a9l4

It's also fixed in dkubb/dm-core because we don't have a
ManyToOne::Proxy object at all. We return plain Resource objects from
many to one accessors.

Dan
(dkubb)

P.S. We'll probably be doing a dm-core and dm-more gem release this
week so this fix will be available via gem shortly.

[Tony Mann]

Dan,

This is great news, and the fix is exactly what I had in mind.

..tony..

[Earle Clubb]

Dan,

>
> P.S. We'll probably be doing a dm-core and dm-more gem release this
> week so this fix will be available via gem shortly.

From which repository (is that what they're called in git?) will the
gems be released: sam or dkubb?

Earle

[Jonathan Stott]

From sam's repository. dkubb's is currently 'hosting' the spec re-write effort, but that is currently at the 'things will get worse before they get better' stage.

Regards
jon

[Dan Kubb (dkubb)]

Hi Earle,

To add to what Jon said, all gem releases currently come from sam/dm-
core and sam/dm-more.

As well, all *critical* tickets and patches are applied to the "sam"
repos so that the next gem will be released with those fixes. However,
when there is a non-critical issue we test in dkubb/dm-core first, and
if it's fixed the ticket will be marked as resolved because dkubb/dm-
core is far better tested than sam/dm-core, and it's going to make it
into the mainline soon anyway. (and by soon I mean approximately 1-2
months)

Since our time is finite, we're trying not to get in a situation where
all effort is duplicated between the sam and dkubb repos, so if it's
non-critical and fixed in dkubb, then we consider the issue resolved.
If someone wants to review dkubb/dm-core and backport some of the
fixes to sam/dm-core so that people can get them earlier, I'm fine
with that (we've seen a couple of those this week), although I'd
prefer that person to help with dkubb/dm-core so we can get it merged
into the mainline faster.

Dan
(dkubb)