Add driver logic to MSSQL engine.

[drmuey]

Changes:

Note sure why it is including the first 3 SHAs (2 from PR #4 and my fork update), these are the ones that it actually includes:

• b620e51 Add driver logic to MSSQL engine.
• 6abf98b Remove unused module Win32::SqlServer
• 905bcb1 Address “Global symbol requires explicit package name” error
• c157b6a Add comment for later follow up
• a7cc192 Run mssql.pm through perltidy

Testing:

• prove -lw t/mod/App-Sqitch-Engine-mssql.t == All tests successful.

FWiW:

We still need (probably issues for)

Update: created https://github.com/brianmckeen/sqitch/wiki/MSSQL-TODO

1. Typical engine tests for mssql.pm (which will be difficult for me to do ATM)
2. POD for new()’s _driver attr (or do we?)
3. Determine if the ?how does $uri->dbi_dsn know what $self->driver to use? comment is a thing or not.
4. Determine if the this being necessary seems like a bug, no? comment is a thing or not.

[drmuey]

@theory

I believe so yes, that is partly what the ?how does $uri->dbi_dsn know what $self->driver to use? comment is about. It could be in here or it could be a new issue since the fork is a work in progress. I am leaning toward a separate issue because, ATM, I don't have access to an MSSQL server.

[theory]

$uri->dbi_dsn just uses a default (DBD::ODBC), it does not try the different drivers. So the connect code will need to assemble a DSN itself based on the driver name returned by _driver.

[drmuey]

@theory

I'll see what I can do, @brianmckeen do you want the DSN part as part if this pull request or are you OK with it being separate?

[drmuey]

@theory if I am looking at it correctly, either

a. the mssql engine can't use the URI object at all (and will need to manually build the DSN)

or

b. we'll need to create a new module, URI::ado, and set the object's uri() to the appropriaely (but its a ro attribute so that not really possible ATM)

or

c. have URI::mssql do the same discovery and use the right one

or

d. ???

@brianmckeen I am thinking that with my lack of familiarity with this part of sqitch and MSSQL it may behoove us to move the DSN part of this change to its own issue after this one, #6, is merged :)

[drmuey]

@brianmckeen I created a wiki page of TODOs that includes the DSN stuff, so I'd say go ahead and process this PR as-is and the DSN voodoo can happen as either of us can get to it.

https://github.com/brianmckeen/sqitch/wiki/MSSQL-TODO

HTH!

[theory]

@drmuey: You'll need to construct the DSN from the URI::mssql object based on the driver you load. I think, though, it might be useful to add an interface to URI::mssql to which you can pass a driver name and it will return the DSN. Something like:

sub dbi_dsn {
    my $self = shift;
    my $driver = shift or return $self->SUPER::dbi_dsn;
    return $self->SUPER::dbi_dsn if $driver eq 'ODBC';

    my $class = $driver eq 'ADO' ? 'URI::_ado'
        ? $driver eq 'Sybase' ? 'URI::sybase'
        : die "Unknown driver: $driver\n";
    eval "require $class" or die;
    return $class->new($self->canonical)->dbi_dsn;
}

This design requires adding URI::_ado. I'm not sure how ADO DSNs are constructed, but a quick search seems to indicate it's similar to ODBC, in which case the implementation might be most easily done by subclassing URI::_odbc:

package URI::_ado;
use base 'URI::_odbc';
our $VERSION = '0.17';

sub dbi_driver   { 'ADO' }

Such a patch should go to the URI::db project.

[drmuey]

@theory excellent thanks, I'll start in via that route ;)

[drmuey]

@brianmckeen Hey Brian, I am working on another pull request and part of it is the AUTHOR section. Would you like me to use the email address you used in the original thread, your git hub URL, or something else?

[brianmckeen]

@drmuey Please use [email protected]

[drmuey]

@brianmckeen awesome thanks! its done ;)