Datamapper DataMapper

Comments and changes to this ticket

• You flagged this item as spam.
  

  asolove (at u.washington) November 28th, 2008 @ 03:08 PM

  A related suggestion: ordering by fields in the join table of a "has n :through => Resource" many-to-many relationship.

• 

  Dan Kubb (dkubb) November 29th, 2008 @ 09:28 AM

  • State changed from “new” to “open”

  I actually think this is a good idea, but we need to be really careful about the API that we design this around.

  IMHO, of all the Ruby ORM API's the most elegant is the one that Ambition provides. I think if it weren't for the ParseTree dependency (which locks it to MRI mostly) it would be something that more ORMs would strive to emulate.

  At the same time I've attempted to make Collection work as similarly to Ambition in many ways as possible. One way that I haven't gotten to quite yet is to emulate Ambition's sort_by syntax:

  http://ambition.rubyforge.org/ad...

  Here's an example of what it would look like for DM:

  User.all.sort_by { |u| -u.age }

  When the Collection is loaded, we could just have the sort_by block yield to the object and sorted normally as an Enumerable. (no need to pay the cost of the DB access when it's already all loaded) When the Collection isn't loaded, we could have it yield to a sort of OrderBy object. That object could support a "*" operator, among others, so that conditions like the above could be described in Ruby code. It should be possible to make it so ParseTree isn't a requirement for this (I think after all is said and done, the only thing that'd require ParseTree is the conditions, due to OR/AND and nesting).

  The only thing this leaves out is the ability to specify a default order for associations. We could make it so :order accepts a lambda, or we could make a :sort_by parameter for the lambda, and have it use the same API as the Collection#sort_by provides.

• 

  Dan Kubb (dkubb) November 30th, 2008 @ 12:45 PM

  • Assigned user set to “Dan Kubb (dkubb)”
• 

  Dan Kubb (dkubb) December 4th, 2008 @ 03:46 AM

  • State changed from “open” to “not-applicable”

  Jack, I think this idea is really good and should probably be brought up on the mailing list if you are so inclined.

  However, we're trying to get away from using Lighthouse as a TODO list and only to track bugs and patches. The mailing list does a good job getting feature requests and suggestions out in public so people can discuss them, while LH doesn't fulfill that role very well in my experience. Stuff thrown into LH tends to only be seen by a couple of people who manage the tickets, but since the reporter thinks it's being taken care of they don't discuss it in any other public forum and it gets forgotten.

• You flagged this item as spam.
  

  jack dempsey (jackdempsey) December 4th, 2008 @ 09:05 AM

  Thanks for the reminder Dan, I'll send a note there later today.