Datamapper DataMapper

Comments and changes to this ticket

• 

  Dan Kubb (dkubb) May 9th, 2008 @ 12:36 PM

  I've seen this happen before. I think its caused by the @collection inside the resource being nil. How this happens I am not sure, since all results, even first(). create a collection object underneath and "attach" it to the resource; and there's nowhere I can think of to unattach it except when done explicitly.

• You flagged this item as spam.
  

  Sam Smoot May 9th, 2008 @ 05:02 PM

  Dan, it's on new records, which don't begin life through a finder call.

  So, I've run into this before as well. If that's really the only problem, we can just tweak Repository.save to assign a Collection for created records. Maybe I'll take a peek today. :-)

• 

  Dan Kubb (dkubb) May 13th, 2008 @ 11:04 PM

  Sam, ah, right, duh. Doesn't it seem unnatural though to assign a newly created record to a Collection just so it can be reloaded? If I was debugging a problem I surely wouldn't expect that to be happening under the covers. It seems too much like a hack.

  There must be another option, perhaps factoring out the reload logic so that both a Collection and a Resource can use the same logic.

• You flagged this item as spam.
  

  Sam Smoot May 14th, 2008 @ 10:24 PM

  Dan, right, but picture this:

  Create a record. Find a record. In the same scope. They should be the same object. So to me at-least, it makes sense that we'd bind created objects to a Collection whatevs>>. That way associations and all other manner of goodness works too.

• 

  Dan Kubb (dkubb) May 14th, 2008 @ 11:56 PM

  The IdentityMap is what keeps track of the resource instance, and allows us to pull out already instantiated resources based on their primary key. Right now Collection sort of acts as a bridge between the Resource and the Identity Map. It handles checking the IdentityMap, registering new resources and populating them with the key information. However I don't think its particularly important that it be the only bridge.

  The logic that handles all this lives in Collection#load, and while it does have a few lines that assign the resource to the collection, and set the resource.collection attribute, the bulk of the logic would probably be better handled by Resource directly, probably as a class method.

  That separation would open the doors so that we could easily register a Resource in an IdentityMap regardless of whether it was instantiated inside a Collection, or created with #initialize.

• You flagged this item as spam.
  

  Ken Robertson May 15th, 2008 @ 02:41 PM

  FYI, fixed this ticket last night while talking with Sam on IRC. Sam checked the fix in.

• You flagged this item as spam.
  

  Sam Smoot May 20th, 2008 @ 09:33 PM

  • State changed from “new” to “resolved”