#354 ✓resolved
Dan Sully

Associations should be first class.

Reported by Dan Sully | June 6th, 2008 @ 12:08 PM

dm-core 0.9.x

When creating an association with the same name as a column name, and trying to query or create using that column name should allow passing of an existing Resource object.

If I have a belongs_to :foo without a property :foo and try to .first(:foo => foo.id), append_condition in query.rb kicks out with:

"Clause #{clause.inspect} does not map to a DataMapper::Property" if property.nil?

If I add a property :foo, and try and pass just the foo object in a first(:foo => foo), I get:

Don't know how to quote #

component_name="Systems" start_run_time=Fri, 06 Jun 2008 15:49:43 +0000 component=1 service_name="production" is_stale=false cluster_name=""


Conversely, if I try and pass new(:foo => foo.id), HasOneToMany::Proxy fails at:

@relationship.attach_parent(@child_resource, @parent_resource) if @parent_resource.nil? || !@parent_resource.new_record?

(emulating what was find_or_create, which Sam added back as first_or_create, but I've not updated. his code would have this same issue

though since it boils down to: first(opts) || new(opts)

this is my current work around: http://rafb.net/p/ZSBoZI23.html, but I'm not sure if that breaks anything else. Either way, it's a very hacky work around.

Comments and changes to this ticket

  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) June 6th, 2008 @ 12:20 PM

    • Milestone cleared.
    • State changed from “new” to “open”

    One problem that this ticket highlights is you can't pass in :foo => foo, where foo is a Resource object, into a query.

    The system should be smart enough to know that if there's a foo_id child key (or whatever the property is called), and the Resource object has an "id" property, that it should automatically transform this to the equivalent of :foo_id => foo.id (according to whatever naming convention is in place, unless the :child_key was explicitly supplied).

    Also it should be smart enough to handle composite keys, so if the Resource's key is (name, region) passing in :foo => foo should translate to :foo_name => foo.name, :foo_region => foo.region under the hood.

    Another problem this ticket shows is that if you name the child key the same as the relationship name, the system has trouble constructing the query. Not sure why this is, but it should be fixed. DM shouldn't force any naming convention onto people, only provide a sensible default that can be over-ridden when necessary.

  • Dan Sully

    Dan Sully September 8th, 2008 @ 04:05 PM

    • Tag set to belongs_to, bug, dm-core, property


  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) January 8th, 2009 @ 04:36 AM

    • State changed from “open” to “accepted”
    • Assigned user changed from “Sam Smoot” to “Dan Kubb (dkubb)”
  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) February 21st, 2009 @ 03:33 AM

    I have done some work on this in a local fork, and have found it to be a bit clumsy to work into the existing framework. From the user's POV it works beautifully, but the internals need more rework before I want to add this to dm-core itself.

    Right now dm-core assumes that all adapters infer the foreign key in the same way that RDBMS' do. For example, if the relationship is named car which maps to the Car model, which has a PK named :id, the FK will be named car_id. Some storage engines don't even have a concept of FKs though, so obviously something needs to change.

    What we need is a way to decouple the FK inference from the Query and Relationship code.

    I'm still unclear exactly how to do this, but there will likely be some sort of callback executed in the adapter when a property or relationship is added to a model in a repository. This will allow the inference code to be mixed-in among other things.

  • Dan Kubb (dkubb)
  • Dan Kubb (dkubb)

    Dan Kubb (dkubb) May 28th, 2009 @ 04:08 AM

    • State changed from “accepted” to “resolved”

    This should now be resolved in dm-core/next. You can safely pass in Resource objects rather than having to specify the FK in the queries.

    From the user's pov, the approach I'm using is perfect. When you pass in a Resource it'll extract the FK components and passes those down to the adapter. (this also works with Collections of Resource objects too)

    In the future I will probably be changing these internals so that the Resource is passed down to the Adapter untouched.. the adapter will be responsible extracting whatever it needs from the Resource. This will allow some neat possibilities in the future.

    However, these are all internal modifications, and this ticket was related to the public API, which has been resolved so I am marking this ticket as resolved.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile »

People watching this ticket

Referenced by