<avdi>
it's a lot of code, but the important bit is at the end, where updating the author's pen names fails to actually store anything new to the database
<avdi>
the reason being that the method responsible for updating it was using aliases of the author it grabbed via an association. When the original author object is stored, it has none of those changes
<avdi>
I have another version where I apply an identity map to ensure that no matter how you get to the author object, it's always the same instance (no aliases).
snusnu has quit [Quit: Leaving.]
jgaskins has quit [Ping timeout: 276 seconds]
jgaskins has joined #rom-rb
<CraigBuchek>
avdi: Out of curiosity, what are you working on in regards to ROM?
<avdi>
CraigBuchek: nothing ATM
<CraigBuchek>
I'm hoping to integrate Virtus with ROM to make a simpler API that could be used in 80%+ of cases to define the map, but leave everything else the same.
<CraigBuchek>
Starting with Virtus + Perpetuity.
<CraigBuchek>
And also adding Virtus to AR, so that I can define attributes in my model instead of having to look in the schema and the model to figure out what the model does.
<avdi>
right now I'm just working on RubyTapas episodes explaining the aliasing problem and the Identity Map pattern
<CraigBuchek>
I'm hoping that will also help as a stepping stone to help people move from AR to ROM.
<CraigBuchek>
avdi: Excellent. I suspected that was a likely answer. ;)
<avdi>
well, and I'm also using the Data Mapper and Identity Map patterns in an app I'm working on, but I'm not using any existing libs
<jgaskins>
avdi: howdy!
breakingthings has quit []
<jgaskins>
avdi: what did you mean about aliasing earlier?
<jgaskins>
regarding the Identity Map, that is.
<dkubb>
I think he may be referring to the problem the IM helps you solve, namely when fetching an object via a key, you can check to see if it was loaded previously by checking for it in the identity map first, and then going to the db afterwards
<dkubb>
ahh, ok, so the reason for the IM is if you modify one instance of the object, that other references will get updated too.. rather than a single session with multiple out-of-sync copies of the object
<dkubb>
I use the term session lightly, not in the sense of a physical object, I mean more like the set of work a given piece of code is doing
<dkubb>
duping saves the extra database call, which is definately a win, but it's more of a side-effect rather than the original purpose behind IM
<avdi>
Yeah, I think of that as the primary purpose of an IM. There may be performance benefits as well, but those are a side benefit.
<dkubb>
afaik anyway, not having been able to speak with Fowler directly
<avdi>
The main thing is getting rid of a whole class of nasty bugs in one fell swoop.
<dkubb>
I had a friend who argued with Fowler for 10 minutes about the interpretation of something in PoEEE before Fowler said who he was :)
<avdi>
hahaha
<dkubb>
it was at a conference and he didn't know what he looked like
<jgaskins>
hehehe nice!
<avdi>
jgaskins: did you see the gist I posted above?
<jgaskins>
Yep, I was having a look a little bit ago.
<jgaskins>
I'll have a closer look tonight. I'm at work, so only halfway paying attention. :-)
mbj has joined #rom-rb
cbuxton_ has quit [Ping timeout: 252 seconds]
cbuxton_ has joined #rom-rb
jordanyee has quit [Quit: MacBook went to sleep.]
jordanyee has joined #rom-rb
postmodern has joined #rom-rb
<CraigBuchek>
jgaskins: I did some work on Pepretuity::Memory last night, regarding the proxy, but only got half way done. Not sure if I'll get a chance to finish it this weekend or not. Heading to Chicago (6 hour drive from St. Louis) this weekend.
<CraigBuchek>
jgaskins: I think duping from the identity map would break it. I can probably write a simple test case to verify.
<jgaskins>
CraigBuchek: You may be right. I originally had it returning the same instance, but I ended up using the Identity Map to determine what attributes had been modified since it was retrieved (so saving wouldn't upload the entire object), which doesn't work if the object is the same instance.
<jgaskins>
I'll need to play around with this. I really appreciate the feedback from all of you on that.
<CraigBuchek>
Ah. Nice way to improve the implementation, but apparently not helpful as an identity map. I'll add it to my ORM TODO list, near the top.
<jgaskins>
Yeah, if it does get rid of what an Identity Map provides, I'll just revert that and use another structure in the mapper to deal with that.
<jgaskins>
avdi, dkubb, CraigBuchek: If any of you can know of a scenario where duping hurts it, I'm really interested.
<jgaskins>
also, avdi, i appear to have completely missed reading that whole part where you explained everything. that's what i get for not paying attention. *sigh* :-)
<jgaskins>
i'll play with the gist you posted this evening before i ask any more questions you've probably already answered.
<dkubb>
jgaskins: ahh, yes, dirty tracking is a tough problem
<jgaskins>
dkubb: yeah, and maybe i've just gone about fixing it the wrong way.
<dkubb>
jgaskins: I need to check how rom-session handles it, but the approach I was planning on was holding a reference to the axiom tuple (a Hash-like instance that represents the raw data from the database) and then compare that against the current state of the object
<mbj>
dkubb: My original rom-session did it like this.
<dkubb>
that should allow us to determine if the object was modified after it was initialized
<mbj>
dkubb: Best side effect: 100% accurate.
<dkubb>
mbj: I'd guess that rom-session does too
<mbj>
dkubb: Yeah.
<mbj>
dkubb: I still "wine" because my fully mutaiton covered implementation is gone. But I know why solnic did it he wanted to connect it "fast" with the rest.
<jgaskins>
dkubb: ahh, okay. off the top of my head, perpetuity mappers pipe the output from the DB straight into the deserializer to get an actual object.
<dkubb>
jgaskins: is there any intermediate object, like a hash or some object that represents a database row?
<jgaskins>
dkubb: i didn't even think of storing that representation straight from the DB
<mbj>
jgaskins: I plan to allow an adapter to see the old and the new tuple. So the adapter can easily do "differencial" updates.
<dkubb>
the only thing to be aware of with this approach is that if you copy a String object over from the db result to the object, and then someone does something like: object.name << ' extra' ... it won't show up as different. so you need to be aware of when you need to dup individual attributes
<jgaskins>
yeah, i implemented something like ActiveSupport's deep_dup to dup attributes, too.
<jgaskins>
mbj: yeah, i'm liking that idea. i had never thought about just using the data structure returned from the DB adapter before deserializing. seems so obvious now. :-)
<dkubb>
you could even store it in an/the identity map if you wanted
<dkubb>
it seems to be something that makes sense to store in the context of a session
<dkubb>
or you could have your object hold a reference to it, but I don't really like dynamically modifying my PORO's, even storing in in @__original__ or something.. I'd prefer something else be responsible for the bookkeeping
<mbj>
jgaskins: Because that datastructure contains all the "specifics".
<mbj>
jgaskins: Doing a "deep diff" must be done db specific.
<mbj>
jgaskins: I'd just love to do 100h straigt on ROM.
<mbj>
jgaskins: Basically I did all pices once. Just need to fit everything together.
<jgaskins>
dkubb: i don't have a "session" concept, really. the identity maps are stored in the mappers, which is intended to be (relatively) short-lived — like the duration of a single Rails request.
<dkubb>
jgaskins: do you have some kind of object that maintains the IMs for the request.. like are you using thread local variables or something to track what is the current session?
<jgaskins>
dkubb: i stole solnic's original idea where you would say `DataMapper[MyClass]`. so `Perpetuity[MyClass]` instantiates a new mapper. what i've been doing in my apps is memoizing that.
<jgaskins>
you guys gonna be online for a while? i've gotta run and pick up my roommate.
<dkubb>
yup
<jgaskins>
alrighty. i'll talk to you in a little bit.