[PATCH] Include ibm_db within the list of database adapters

Since ibm_db is not officially support Rails, it shouldn't be listed as valid adapter.

Email the rubyibm guys and tell them to add this patch on there end. If necessary, create a imb db rails plugin that makes it easier to integrate.

Hi Josh,

As one of the rubyibm members, allow me to provide some context with regards to this patch and the IBM data servers support for Rails.

First, I should clarify that rubyibm already provides IBM_DB adapter/driver as plugin and gem, and does already make it very easy to integrate. The IBM_DB plugin install is seamless (no manual step involved), while the IBM_DB gem install only requires the patch in discussion (i.e. adding the ibm_db to the list of adapters).

Once the RAILS_CONNECTION_ADAPTERS list includes ibm_db, the gem enables Rails applications to work with any IBM data server client (DB2 on Linux, Windows, Unix, i5 and zOS, and soon enough Informix IDS). That opens an important segment of the enterprise market, and I am pretty sure everyone understands how this furthers the penetration and success of Ruby and Rails in the long run.

That being said, while ibm_db is not yet officially supported by this very much admired and appreciated Rails framework, we released a Production/Stable release 0.6.0 of IBM_DB adapter/driver gem that passed ActiverRecord's compliancy tests, with the exception of a handful of test cases that are documented in the gem, which do not apply to IBM data servers (as in majority of cases do not apply to other vendors either).

Having the ibm_db adapter listed in the active_record.rb besides {mysql postgresql sqlite firebird sqlserver db2 oracle sybase openbase frontbase} it's a tiny change that will increase Rails visibility in the enterprise and will in no way impact any other functionality.

Is there any specific concern remaining that we need to address before your team would consider such a proposal? Is there any other compliancy step required to make this happen? We do have another patch proposal for supporting db:test:purge, and we can make every effort to accommodate anything else that you deem necessary.

I am looking forward to see rubyibm team bring more contributions to this common effort.

Thanks, Alex Pitigoi

Alex, is adding the adapter to the list yourself not working out?

I'm puzzled that you guys did your own thing instead of contributing to the existing db2 adapter.

It looks like you have being trying to modify Rails directly (http://www.ibm.com/developerworks/db2/library/techarticle/dm-0705chun/). Bad practice.

Perhaps you try adding your db to in your environment config.

...
# Specifies gem version of Rails to use when vendor/rails is not present
RAILS_GEM_VERSION = '1.2.3' unless defined? RAILS_GEM_VERSION

RAILS_CONNECTION_ADAPTERS = %w( ibm_db ) 

# Bootstrap the Rails environment, frameworks, and default configuration
require File.join(File.dirname(__FILE__), 'boot')
...

If you don't like that, whip some thing up for adding adapters in the rails initializer.

Adding every unofficial db to the list is not the answer.

Bitsweat, adding the adapter to the RAILS_CONNECTION_ADAPTERS list in active_record.rb is what we have been telling customers all along in our documentation, but it's obviously not an out-of-the-box experience, and as surprising as this might sound, some may perceive that as intimidating :-) That's why we have provided the plugin alternative which fortunately allows an initialization "hook" which enables us to insert the ibm_db adapter dynamically at runtime. Reality is, customers prefer a gem install, therefore a need to hook our adapter into the ActiveRecord gem manually, unless your team gracefully allows this minimal change.

I can also understand your confusion, and I wish I can provide a simple and comprehensive explanation in a short phrase, but I think others have expressed this more clearly in a few articles I added as references below. The short story is: software assets can only be distributed without legal liability if the "pedigree" is warranted. That being said, our team can also rely only on specifications to implement drivers/adapters, and we cannot legally "take in" code or even browse existing implementations in any of the exiting Ruby gems or Rails plugins. I can only imagine how much more I have increased your initial puzzlement, but you know... legal counselling is a complicated matter :-)

That being said, I really hope your team would be sensible to our constrains, and will not allow DB2 and Informix IDS to be single out from the list of supported database vendors. We have a common goal in making Ruby on Rails successful, and we hope to provide further more appealing contributions to this community.

Josh, can you please help me understand which part of that article you reference is implying the bad practice? It wasn't certainly our intent, but rather missing specification on what is allowed and what not, but we are looking to learn and address any wrong-doings. If you, by any chance, refer to adding ibm_db to the active_record.rb manually, that was what we believed to be the simplest way out.

You also already mentioned twice the officially versus unofficially supported databases. My understanding, and correct me if I'm wrong, is that not all databases in that exiting RAILS_CONNECTION_ADAPTERS list are officially supported anyway, besides the "first ones to the party". Also, pointing us to the official list and your team's position on this would be of great help in our understanding.

You are also right in saying that adding to this list is not really the way to go in the long run (although I doubt there are many other db vendors left out), but I am afraid there's no "hook" to allow a new adapter gem to self-insert. When there was such a "hook", as is the case with the Rails plugin, we used it. So, please bear with me and maybe guide me if I am missing something.

And one last word, Josh, on this already way too long explanation... why do you think DB2 and Informix deserves to be singled out of such a large list of databases ?

Thanks, Alex

References: http://www.langmichener.ca/index.cfm?fuseaction=content.contentDetail&id=9478&lid=0 http://www.out-law.com/page-391

See pastie example (http://pastie.caboo.se/64455) for adding the db in environment.

You are right, there is no great hook. It would be awesome if this worked.

  config.connection_adapters += %W( ibm_db )

A patch like that would certainly be acceptable for Core.

Fair enough, Alex. As a heads up, this brittle mechanism will go away shortly. We'll just require the database referenced in config/database.yml

Josh, config.connection_adapters = ['ibm_db'] does work already

I assume Alex is looking for it to work with just a gem install.

(In [6833]) Load database adapters on demand. Eliminates config.connection_adapters and RAILS_CONNECTION_ADAPTERS. Closes #8456.

Hi Jeremy,

This is a remarkable gracious solution for this dynamic loading and we thank you for your timely resolve. I just tested Edge [6833] and the IBM_DB adapter gets loaded from the gem seamless. Awesome!

The only drawback to current state is that it does not seem to handle plugin install as well. I guess I still have time to dig into this until the next release of the ActiveRecord (ibm_db plugin install will be broken), but it would help me a lot if you can provide some hints.

As I mentioned before, we are constraint with regards to Rails code browsing and figuring out a solution without seeing the code could be difficult at times :-} ...I also believe IBM_DB plugin (or gem) shouldn't ever interfere with other Rails gems install path or files.

Many thanks, Alex

Plugins are the wrong place for database adapters since other plugins expect the database to be accessible already.

Please use a gem install rather than hacking up the initialization process. This won't change unless we add a special case for database plugins, which is unlikely unless it offers some great benefit that a gem does not.

Your other option is to simply rename the plugin to load ahead of any others.

(Also, no offense, I'm ignoring the legal talk. You're insane to endure it when Rails is so liberally licensed.)

(In [6839]) Missed commit from [6833]. References #8456.