Create and deliver personalized experiences across digital properties at scale
Build engaging websites with intuitive web content management
Leverage a complete UI toolbox for web, mobile and desktop development
Build, protect and deploy apps across any platform and mobile device
Build mobile apps for iOS, Android and Windows Phone
Rapidly develop, manage and deploy business apps, delivered as SaaS in the cloud
Automate UI, load and performance testing for web, desktop and mobile
Optimize data integration with high-performance connectivity
Automate decision processes with a no-code business rules engine
Globally scale websites with innovative content management and infrastructure approaches
Content-focused web and mobile solution for empowering marketers
Faster, tailored mobile experiences for any device and data source
UX and app modernization to powerfully navigate today's digital landscape
Fuel agility with ever-ready applications, built in the cloud
It’s interesting to note how often we hear someone say, “Well, I’m using Hibernate, so I don’t really care about JDBC.” In fact, many think they don’t even need a JDBC driver at all, not realizing that the driver operates under Hibernate.
Hibernate has a lot of benefits – it is flexible, and does a fantastic job of level-setting the different kinds of drivers that you put under it. You can tell it what driver to use or which database back-end it’s plugging into. The problem is that most drivers out there simply cannot be configured once they’re already deployed in a Hibernate environment.
Issues can really start to crop up when you don’t consider your JDBC driver early in the process, and chances are you are going to pay for it later (which is always more expensive!). Many vendor drivers are coded in a way that extends the JDBC API, including additional methods that they think should be included in the spec – knowing full well if you use them then you’ll not be able to move to a different database or driver without code changes. This can in no way be seen as a clean spec implementation.
When applications are coded to a modified, vendor specific spec, it becomes really hard to move to other environments and retain functionality. When used under a framework like Hibernate, which has only been coded to the original spec, you’re going to find yourself losing some functionality unless you’re willing to actually change Hibernate code itself, taking away time you could be using to make your product better!
Here at Progress DataDirect, we get really excited about the idea of configuring your drivers without having to worry about the framework it’s under. It’s something we call codeless configuration, where we help customers configure their driver without the need to change any code! This makes it much easier to tweak because you can make modifications at the connect option level – and not at the API level. This means that anyone can do it – and without the effort needed for a more involved API level modification.
For a practical example, imagine an IT worker at a hospital, which has many applications written on Hibernate with a JDBC driver underneath. Imagine this guy (or gal!) deploys the application and runs into an issue – let’s say he finds a memory leak, or the application is using too much memory. He then goes looking into the documentation for the driver and eventually finds that the driver he’s using has a way to tweak the amount of memory his application is using – sweet! However, the only way to tweak the memory usage for that Statement is to cast to a vendor specific object and call a proprietary method. Hmm….now his options are to live with the memory problem or modify his Hibernate instance (code change, recompile Hibernate, etc.) to use the cast and proprietary method. This sucks!
Let’s imagine that the frustration level was too much and he instead went a-Googlin’. He wants to configure the driver without touching code; a simple connection string change would be nice. Asking the great Google to show him a way to do ‘codeless configuration’ on a JDBC driver turns up some interesting results. He finds that there is a driver that allows him to configure the memory usage for his Statement using a connect option, and before lunch his memory issues are now a distant memory. Lucky for you, you don’t have to consult Google to find a driver that can do this, because we offer one you can download and try today. :)
I think it’s really cool that we have a way to help developers get the most bang for their buck with their data access choices. Codeless Configuration is one of those game changing ideas that benefits everyone and frees us to code to a standard the way it was meant to be – without worrying about whether we’re locking ourselves into a specific solution and instead being confident that we can reuse our code when we need to and still have the flexibility to tune based on our application needs.
As Senior Director of Research & Development, Jesse is responsible for the daily operations, product development initiatives and forward looking research for Progress DataDirect. Jesse has spent nearly 20 years creating enterprise data products and has served as an expert on several industry standards including JDBC, J2EE, DRDA and OData. Jesse holds a bachelor of science degree in Computer Engineering from North Carolina State university.
Copyright © 2017, Progress Software Corporation and/or its subsidiaries or affiliates.
All Rights Reserved.
Progress, Telerik, and certain product names used herein are trademarks or registered trademarks of Progress Software Corporation and/or one of its subsidiaries or affiliates in the U.S. and/or other countries. See Trademarks or appropriate markings.