Can't get v. 1.0.0 of SQLServer ActiveRecord adapter

I am attempting to get the 1.0.0 version of the SQLServerAdapter from
the gems.rubyonrails.org gem repository.

It isn’t there. See below:

~ weyus$ sudo gem install activerecord-sqlserver-adapter --source
http://gems.rubyonrails.org --version 1.0.0.
Bulk updating Gem source index for: http://gems.rubyonrails.org/
Bulk updating Gem source index for: http://gems.rubyonrails.org/
ERROR: could not find activerecord-sqlserver-adapter locally or in a
repository

Now if I don’t ask for a specific version (by removing the --version
option above), I get the very latest point revision in the repository,
which is 1.0.0.9216, along with the latest point revisions of both
activerecord and activesupport (2.0.2.9216).

sudo gem install activerecord-sqlserver-adapter --source
http://gems.rubyonrails.org
Bulk updating Gem source index for: http://gems.rubyonrails.org/
Bulk updating Gem source index for: http://gems.rubyonrails.org/
Successfully installed activesupport-2.0.2.9216
Successfully installed activerecord-2.0.2.9216
Successfully installed activerecord-sqlserver-adapter-1.0.0.9216

I’m not interested in being this “close to the edge”.

Is there any way that I can get the 1.0.0 version of the SQLServer
adapter?

Thanks,
Wes

P. S. Somewhat related (given the point releases above) is that once I
install this adapter, gems.rubyonrails.org is automatically added to my
sources for gem, and then if I ask for a gem update for Rails, I will
get the very latest point release of all of the Rails components.
Again, I really don’t want them. I have to remove the
gems.rubyonrails.org source to keep this from happening.

On Apr 28, 8:40 am, Wes G. [email protected]
wrote:

I am attempting to get the 1.0.0 version of the SQLServerAdapter from
the gems.rubyonrails.org gem repository.

It isn’t there. See below:

Download the source from svn/github and build it yourself? I would
imagine the 1.0.0 release would have been tagged (and if not you
should be able to work out when it what revision corresponds to the
release).

Fred

Fred,

Is there an official released version of the SQL Server adapter? I was
assuming it’s 1.0.0, but maybe it’s not, maybe it’s 1.0.0.9216. (I
wonder if this is the case for all non-standard AR adapters)

If it is 1.0.0.9216, then I assume I need to use this point rev. of
Rails, which is 2.0.2.9216.

Are these point releases stable or are they nightly snapshots? I’ve
heard too many stories of people on edge who waste hours tracking down
bugs that someone checked in to edge. If these are snapshots that are
very close to edge, I’m not really interested in developing against
“nightly build” type releases if I can avoid it. Perhaps I’m being too
conservative.

Sure, I can look around in the SVN/github repo. and find what I need
myself, but I feel like the distribution of the SQL Server adapter
should be a little more straightforward that that.

Wes

On Apr 28, 9:08 am, Wes G. [email protected]
wrote:

Fred,

Is there an official released version of the SQL Server adapter? I was
assuming it’s 1.0.0, but maybe it’s not, maybe it’s 1.0.0.9216. (I
wonder if this is the case for all non-standard AR adapters)

If it is 1.0.0.9216, then I assume I need to use this point rev. of
Rails, which is 2.0.2.9216.

Are these point releases stable or are they nightly snapshots? I’ve

It’s not even a nightly snapshot - it just means revision 9216 from
svn. The reason that the gems get the revision number appended is
basically so that the next version of rails looks like a newer version
(ie 2.1 > 2.0.2.9216).
The whole point of ousting the adapters out of core was so that
development and release of these adapters is not tied to the same
release schedule as the rest of rails. As it happens, subversion seems
to say that the sqlserver adapter basically hasn’t changed since 2.0.0
was released (ie 1.0.0 of the adapters) (just a missing require
somewhere) and so you’d be perfectly safe using the latest and
greatest, and that would not require you to run edge rails itself (and
if the gem itself says so you should be able to fix that quite easily.

heard too many stories of people on edge who waste hours tracking down
bugs that someone checked in to edge. If these are snapshots that are
very close to edge, I’m not really interested in developing against
“nightly build” type releases if I can avoid it. Perhaps I’m being too
conservative.
It’s understandable. I don’t run production stuff against edge.

Sure, I can look around in the SVN/github repo. and find what I need
myself, but I feel like the distribution of the SQL Server adapter
should be a little more straightforward that that.

Arguably, but these sort of things are very much dependent on whether
someone steps up and handles these sorts of issues, so hassle the
maintainer, volounteer to help out yourself etc…

Fred

Frederick C. wrote:

On Apr 28, 9:08�am, Wes G. [email protected]
wrote:

It’s not even a nightly snapshot - it just means revision 9216 from
svn. The reason that the gems get the revision number appended is
basically so that the next version of rails looks like a newer version
(ie 2.1 > 2.0.2.9216).

So this means these “release numbers” basically identify individual
builds?

The whole point of ousting the adapters out of core was so that
development and release of these adapters is not tied to the same
release schedule as the rest of rails.

I definitely get this, and agree with the new setup. But it seems like
when the adapters got pulled out of Rails, they were not themselves
“promoted” to units of software that are released, just like
activerecord, actionpack, etc. To me, since they were basically
extracted out of activerecord, they should be managed in the same way
from a release perspective.

Sure, I can look around in the SVN/github repo. and find what I need
myself, but I feel like the distribution of the SQL Server adapter
should be a little more straightforward that that.

Arguably, but these sort of things are very much dependent on whether
someone steps up and handles these sorts of issues, so hassle the
maintainer, volounteer to help out yourself etc…

I wonder if this shows up as an issue with the other “second tier” AR
drivers,
I will try and check a couple out. I’m willing to help, but it kind of
feels like this is the job or whoever maintains the package, so I either
need to get them to do it, or become that person.

Thanks for the thoughtful responses.

Wes

On 28 Apr 2008, at 20:20, Wes G. wrote:

So this means these “release numbers” basically identify individual
builds?
Yup. Individual check-ins (9216 is the latest you’ll see though now
that rails has moved to git)

extracted out of activerecord, they should be managed in the same way
from a release perspective.
I think it’s just lack of love. For the sql server adapter at least,
there’s only been a handful of commits. I know for a fact that AR’s
unit tests are currently most likely broken for sql server (because I
broke them)

Fred

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs