Don't like ads? PRO users don't see any ads ;-)
Public Pastes
Guest

Untitled

By: a guest on Jun 2nd, 2012  |  syntax: None  |  size: 2.54 KB  |  hits: 15  |  expires: Never
download  |  raw  |  embed  |  report abuse  |  print
Text below is selected. Please press Ctrl+C to copy to your clipboard. (⌘+C on Mac)
  1. ## Problem
  2.  
  3. Currently, relationships are stored in a hash. This means that the order in which they were created gets lost.
  4.  
  5. * A model with a composite primary key that is made up of two foreign keys (e.g. a join table)
  6. * Only the relationships are defined (using #belongs_to)
  7. * Properties are *not* explicitly defined (using #property)
  8.  
  9. class PersonTask
  10.   include DataMapper::Resource
  11.   belongs_to :person
  12.   belongs_to :task
  13. end
  14.  
  15. PersonTask.get(person_id, task_id)
  16.  
  17. The above call to #get might not work as expected. What we expect is that just like with properties, the two calls to #belongs_to establish two (foreign key) properties in the PersonTask model, first :person_id, then :task_id. Because the relationships are stored in a hash, there's no guarantee that we retrieve them in the same order we were putting them inside. At some point (before automigrating) DM "resolves" the two relationship definitions and finds out that it needs to establish properties for them. The problem now is that it didn't remember the order in which the relationships were defined, and thus doesn't know the order in which to define the respective properties. Since #get relies on the order in which the key properties were defined to map the arguments to properties, there's obviously a problem.
  18.  
  19. ## Proposal
  20.  
  21. Currently, relationships are stored in a hash
  22.  
  23. https://github.com/datamapper/dm-core/blob/master/lib/dm-core/model/relationship.rb#L56
  24. https://github.com/datamapper/dm-core/blob/master/lib/dm-core/model/relationship.rb#L21
  25.  
  26. There's already 2 set implementations in the codebase, properties are stored in a PropertySet
  27.  
  28. https://github.com/datamapper/dm-core/blob/master/lib/dm-core/property_set.rb
  29. https://github.com/datamapper/dm-core/blob/master/lib/dm-core/model/property.rb#L131
  30.  
  31. and Model keeps track of its descendants in a DescendantSet:
  32.  
  33. https://github.com/datamapper/dm-core/blob/master/lib/dm-core/support/descendant_set.rb
  34. https://github.com/datamapper/dm-core/blob/master/lib/dm-core/model.rb#L60
  35. https://github.com/datamapper/dm-core/blob/master/lib/dm-core/model.rb#L79
  36.  
  37. The plan is to provide an OrderedSet class that provides both set semantics and retains insertion order. With that class available, we could probably have a SubjectSet class that "has a" OrderedSet and provides common API for all its descendants, being: PropertySet, RelationshipSet and DescendantSet. This refactoring would eliminate the bug explained above and would also clean up duplicated code (currently in PropertySet and DescendantSet, and in the new RelationshipSet)
create a new version of this paste RAW Paste Data