Rails core - Jan 2006 - Proposal: Deprecate ADO support in the SQL Server adapter

The SQL Server adapter can currently operate in two modes, ADO and
ODBC, each of which uses a different interface to access the db.  The
ADO interface is currently the default, while ODBC can be specified as
an option.

I propose this situation is reversed, and that use of the ADO
interface is deprecated, if not removed altogether.  Here are some
reasons, I'm sure there are more:

a) ADO uses a COM interface, so can only be used on Windows.  ODBC
works across all systems

b) The activerecord test suite passes fine using ODBC, but under ADO
occassionally fails with  strange win32ole related errors.  Based on
my own experiences with deployed apps, it seems less reliable.

c) The ADO DBI driver is half finished, with TODOs throughout the code.

d) The ODBC dbi driver is provided in the windows ruby one-click
installer, while the ADO driver has to be specifically installed.

e) Although DBI should mean a uniform interface to the db, there are
some quirks, such as the ADO adapter returning strings where ODBC
returns DBI::TimeStamp

f) Having only one interface would make development and documentation
of the adapter far more manageable.

So what do people think?  Does ADO have advantages over ODBC I'm not
aware of?  Are there other reasons to keep ADO support in the adapter?

Unless people have significant objections, I'll create a ticket and
patch to deprecate ADO, and update the wiki instruction pages
accordingly.

Tom

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

> So what do people think?  Does ADO have advantages over ODBC I''m
not
> aware of?  Are there other reasons to keep ADO support in the adapter?
>
> Unless people have significant objections, I''ll create a ticket
and
> patch to deprecate ADO, and update the wiki instruction pages
> accordingly.
I don''t really know enough about SQLServer to object. I know that I
had to install the ADO driver to connect to one of my client''s
servers. How would one go about it with ODBC?
Kev

> > Unless people have significant objections, I'll create a ticket
and
> > patch to deprecate ADO, and update the wiki instruction pages
> > accordingly.
>
> I don't really know enough about SQLServer to object. I know that I
> had to install the ADO driver to connect to one of my client's
> servers. How would one go about it with ODBC?
Providing you've used the one-click ruby installer for windows, you
shouldn't need to install anything else.  Here's an example
database.yml section:

development:
  adapter: sqlserver
  mode: ODBC
  dsn: Driver={SQL Server};Server=(local);Database=rails_development;Uid=sa;Pwd
As you can see, you can pass a full connection string as the dsn.  I'd
like to factor the common parameters out of this string (server, db,
password, user) and use standard yaml
attributes to specify them, but I need to check how this will affect
FreeTDS installations (required to connect from mac, linux) before
doing this.

As an alternative, you can also create a named connection in the Data
Sources control panel, and just pass in the name.

Tom
--
email : tom at popdog.net

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core

On 1/29/06, Tom Ward <tom@popdog.net> wrote:
> As you can see, you can pass a full connection string as the dsn. 
I''d
> like to factor the common parameters out of this string (server, db,
> password, user) and use standard yaml
> attributes to specify them, but I need to check how this will affect
> FreeTDS installations (required to connect from mac, linux) before
> doing this.
Why not have something like this:

server: &server
  driver: /opt/local/whatever-driver.so   # or whatever
  user: my_login
  password: M$_wh0r3
  server: 192.168.2.666
  tds_version: 8.0                                     # if anyone needs this

development:
  database: rails_development
  mode: ODBC
  << *server

special_environment:
  database: rails_whatever_db
  mode: ODBC
  dsn: whatever # overrides any other parameters given
  << *server

... it shouldn''t be too hard to check if a ''dsn'' key
is present, and
if not try and build the DSN string from the server/uid/pwd/driver
values? That way awkward folks on Macs who are too lazy to figure out
how to get proper DSN strings to work (this is me, btw) can set up
their connections in ODBC Administrator and still do their job.

(AFAIK, this code semi-exists in the ADO part of the connection setup
already anyway)

- james

> Why not have something like this:
>
> server: &server
>   driver: /opt/local/whatever-driver.so   # or whatever
>   user: my_login
>   password: M$_wh0r3
>   server: 192.168.2.666
>   tds_version: 8.0                                     # if anyone needs
this
>
> development:
>   database: rails_development
>   mode: ODBC
>   << *server
>
> special_environment:
>   database: rails_whatever_db
>   mode: ODBC
>   dsn: whatever # overrides any other parameters given
>   << *server
That's pretty much what I have been planning.  There are two issues I
need to watch out for though:

1) The connection string can specify all sorts of extra parameters
(dsns, file dsns, etc), I don't want to remove that for people who
might need it, so the option to specify a 'dsn' must remain
(shouldn't
be a problem)

2) FreeTDS may require different connection parameters than ODBC
through windows.  I don't even know if it accepts a full connection
string.  I'd like to be able to specify the following in config.yml,
and connect from windows/mac/linux with minimal extra work:

  development:
    adapter: sqlserver
    database: queen_is_dead
    user: morrissey
    password: shoplifters of the world
    server: smiths1

Tom

P.S
> password: M$_wh0r3
Slash-dot suck-up

_______________________________________________
Rails-core mailing list
Rails-core@lists.rubyonrails.org
http://lists.rubyonrails.org/mailman/listinfo/rails-core