#268 ✓resolved
Nathan Herald

Doesn't reload a newly created record

Reported by Nathan Herald | May 9th, 2008 @ 12:31 PM

If you look at my attached test file, you will get the following result from running it.


2: undefined method `reload' for nil:NilClass

It seems that reload is failing because of something to do with looking up a key wrong or something.

Comments and changes to this ticket

  • Dan Kubb (dkubb)

    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.

  • Sam Smoot

    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)

    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.

  • Sam Smoot

    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)

    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.

  • Ken Robertson

    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.

  • Sam Smoot

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

    • State changed from “new” to “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