We have just released a new version (2.5) of our O/R mapping tool, Genome. You may already have noticed that TechTalk frequently releases new versions of Genome. When we created the first automated data access layer implementation for one of our .NET projects four years ago (which later became Genome), we tried to build up a core framework that can be easily extended in many ways without breaking the existing public API. This allows us to provide frequent updates with improved functionality that can be used easily by our customers without spending valuable efforts on integration.
Genome 2.5 is a bit different. You might not notice any difference because this release is as backwards compatible as previous ones: when you upgrade, you most probably don’t have to do anything else but modify your references to Genome to use the new version. However, Genome 2.5 introduces a big change, or at least a bigger one than usual: we have integrated support for Oracle and Microsoft database server platforms into one build. This will also allow us to extend Genome’s support for further database platforms in the future more easily and it has made Genome, our lovely child (as we’re used to calling it), a teenager who has successfully graduated from elementary school.
You’ll probably say: “What’s the big deal? There are several O/RM products on the market that support multiple database platforms.” Well, that’s true, but there can be significant differences in how they support a specific database platform. The challenge is not to provide an abstraction for the various SQL syntax flavours used by different database platforms but to deal with the semantic differences found in those platforms, such as identity generation (automatically incremented field value versus sequence), limiting the result set to a maximum row count (TOP n vs. ROWNUM <=n), handling LOB parameters in grouped database commands or different database type systems.
In Genome 2.5 we have tried to provide transparent integration with the different database providers. And in most cases, it just works! You simply change the database provider setting in the properties of your DataDomain schema project, modify the connection string, and your application is ready to run on a different database platform. We have found, however, that providing a safe, straightforward and transparent solution is not always possible. Because of the semantic differences mentioned before, there are cases when you cannot achieve exactly the same functionality on another database platform. One problem is that of the empty string, to finally arrive at the topic I wanted to talk about.