I’ve looked at clouds from both sides now…
I stumbled across a very cool cloud-based music service called SoundCloud (http://www.soundcloud.com) today. I love it for two very different reasons. First, it’s a great (maybe even killer) application of cloud computing technology, taking advantage of the Great Server Farm In the Sky to solve a real problem. Second, I love the solution itself.
See, technology is my day job. When I’m not working (or walking the dog, or schlepping kids around town), I usually have some sort of musical instrument in my hands. or in front of me. Guitar, mandolin, bass, keyboards, drums and trumpet, for now. Hope to add to the collection soon – I think I need a bouzouki. Or maybe a dobro. But I digress…
When I have a block of free time and a little peace and quite in the house, I like to break out my recording gear and see what I can throw together. And, occasionally, share it with a few friends to see what they think. Or even send a track to a friend who’s a real drummer to lay down a drum track for me to mix in later.
In the past, sharing music online has been inconvenient at best. Oh, there are music sharing sites like SoundClick, or social sites like MySpace that cater to musicians. But they all have some pretty serious limitations (like having to actually log into their service to find and listen to tracks).
SoundCloud is different. It’s a seriously open, cloud-based music storage and publishing service. I just signed up an hour ago, and within minutes I was uploading my first track. (I love, by the way, that you specify the file to upload first, and it automatically starts uploading while you fill in the track info form.)
But the really cool part is the openness of the service. There’s no need for anyone to go to their site to hear my music. I can email it to them, or drop a widget into Facebook or a blog entry (as I’ve done here), and voila. Music. Where I want it. No strings attached.
And now, if you’ll excuse me, I have a recording project to dive into…
Of Entities and Identities
I really like Hibernate. Sure, it can be frustrating at times, the learning curve can be steep, and some of the exceptions you get when you do stupid things aren’t all that helpful. But the fact that it’s frustrating and hard to learn are manifestations of the fact that it’s tackling some really thorny problems. And the cryptic-exception issue does get a little better with each release.
There is one thing, however, that has bothered me since I started using Hibernate several years ago. A deep bother. Not a “this is a nuisance, but I can live with it” bother, but more of a “this is so fundamental an issue that there just has to be a better solution to it than is being offered by Hibernate’s authors” bother.
The problem: bridging the gap between object identity and database identity. In most modern database schemas, tables are defined with a numeric primary key column, which is populated through some unique key assignment mechanism (Identity columns in SQL Server or MySQL, sequences in Oracle, etc).
This works great at the database layer. But problems arise in the JVM (or CLR for you NHibernate folks). In order for objects representing database entities (those managed by Hibernate) to be handled properly in collections (including Hibernate cache), objects that have the same database identity need to be recognized as equals as well. In Java, this means overriding equals() and hashCode() such that any two objects that represent the same database entity will be equal, and return the same hash code.
The “obvious” solution, at first blush, would be to base equals() and hashCode() on entity ID values. This works great for entities created by Hibernate, which represent existing rows in a database, all with unique ID’s. The problem has to do with new entites that you create programmatically, which haven’t yet been saved. Those entities will typically have a null ID value – and if you base equality on ID values, any two unsaved instances will be considered equal.
There are actually two problems when dealing with unsaved entity objects. The first, as stated above, is that they don’t yet have a unique identity – so multiple new instances will collide in collections like Maps and Sets. The other problem is that the identity of these objects will be set at some point, which violates part of the contract of hashCode() – the part that says its value must not mutate over time.
To avoid all of thes problems, Hibernate’s authors have long recommended a workaround – use “natural keys” instead of identity values for equals() and hashCode(). The problem with this is that many entities simply don’t have a natural key – that is, a set of one or more attributes whose values uniquely identify the entity. And those that do often fail the hashCode() qualification that the value should not change over time.
There are other possible solutions I’ve seen or come up with myself, but all had at least one glaring weakness. It seemed that there was no silver bullet for dealing with database-generated identity values in Hibernate.
And therein lies the silver bullet. Don’t use the database (or Hibernate) to generate identity values.
I stumbled across a wonderful article on O’Reilly’s OnJava site that quite clearly describes this problem (in more detail than I do here), and offers what I believe to be the only real solution. Check it out at http://www.onjava.com/pub/a/onjava/2006/09/13/dont-let-hibernate-steal-your-identity.html.
And now, as I look out the window at the late February snowstorm, I think maybe it’s time for me to hibernate…
