Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
The actual town of 'Jersey Shore' is located in Pennsylvania - not in New Jersey
When compared to Hibernate, ActiveRecord is the clear winner for ease of use, but the clear loser for configurability. For most of the projects I work on, I'm happy to trade one for the other and go with ActiveRecord (not to mention all the other perks I get from using the rest of the Rails Framework.) However, I'm a bit disappointed (or maybe simply misinformed,) when it comes to object identity in ActiveRecord.
The Hibernate framework has a clear and understandable separation between object identity and the primary key of an entity. Object identification is the job of the JVM, and Hibernate guarantees that objects created within the same hibernate session will have a one-to-one correspondence to database records (meaning there won't exist two objects with different ids and the same primary key.) There is a clear distinction between the concepts of primary key and object id, and I think hibernate does a good job at keeping them at a reasonable distance from each other.
ActiveRecord, it appears, operates by enforcing the one-to-one correspondence between objects and database rows all the time. It does this by hijacking the id method of the Object class and returning the entity's primary key. Coming from the java world, this is confusing. I would think that pure object identification should be the job of the ruby interpreter, and not involve ActiveRecord at all. The problem with this approach is that disconnected new objects have no id - calling Object.id returns nil. But the object must have some identification within the interpreter, no?
I have to admit that the guarantee of never having two objects represent the same entity regardless of the 'session', (although the session concept doesn't really apply in ActiveRecord,) is appealing. But the problem I have is that there is no way to compare disconnected new entities unless we provide an == method, which I guess isn't a bad idea, but we'd be comparing natural candidate keys which won't be effective 100% of the time.
I have to ask you the reader (if anyone is in fact reading this,) to take a look at the rdoc for the Object#id method:
nil would never be returned here given this description.
Well, it turns out that my last post was in fact fueled by my own mis-information. While browsing through David Black's Ruby For Rails book this afternoon, I stumbled upon a discussion involving the somewhat colorful history involving object identification in Ruby.
It turns out that there are actually 3 methods on the Object class used for identification.
Object#id
A more careful look at the Rdoc specifies that this method is soon to be deprecated (why didn't i see that yesterday!?) I believe that this was traditionally used for unique identification, but was found to be over-ridden too often to be reliable. Object identification is far too ubiquitous to be left into the hands of such a popular method name as id, which leads us to...
Object#__id__
This obscure looking call was added as an additional means to getting at the object id. The idea was that since the name is so obscure, it is unlikely that anyone would ever want to over-ride it (does Ruby have no concept of final!) I guess the name was too obscure to be usable though, since the next method was added later on down the road.
Object#object_id
The (hopefully) last addition to this saga which is yet another means at getting to the object id. I suppose this is the preferred method to use these days as it is left untouched by ActiveRecord.
My only question is, what happens if you over-ride all three of these?
Monday, June 26, 2006 06:05 PM EDT