hardcoded primary key

[Excelan]

hardcoded primary key

[metaskills]

Totally understood. The hacks we have had to do in the 2.x version of the adapter are not the best and the work in the 3.x version avoids all this. So this will be a 2.x patch.

Our options are limited to raw string scanning to find a table name and then reflect on the primary key of that table, again assuming we find a properly named AR class based on the singular table name. Or trusting the SQL format enough to find an ID in it. Or ultimately falling back to just id as coded now. There are helpers in the adapter for doing this.

Would you care to take a stab at it, write a regression tests and submit a patch? If so, this work should be done in the 2-3-stable remote tracking branch.

[Excelan]

I'm really sorry Ken, for now I'm just a blind kitten in ruby and rails. :(
I'd love to, but googling tutorails isn't a quick way to mastering ruby :)
Probably I'll try.

[metaskills]

That's OK, I can do this, it will just take me awhile, but I will get back to this after the rails3 work.

[Excelan]

I was excited rail couple months ago, and then again after the railsconf and forthcoming rails 3 anouncement. So I was keen to apply rails3 power to my legacy database. Soon i found out that there is no sqlserver-adapter for rails3 yet and started with rails 2.3
So rails 3 adapter is definitely preferable :) Thank you, for all your work.

There are some other hardcoded restrictions. For example it is also imposible to organize abstract connection (:abstract=>true) with legacy column names. So I create views with proper names as a workaround.

[metaskills]

Interesting, I've used abstract classes in 2.3 w/adapter for some time. Can you be specific? FYI, the adapter has great support for views too.

[Excelan]

Shot me. :)

I meant :polymorphic

belongs_to :Owner, :polymorphic => true, :primary_key => :Id, :foreign_key => :OwnerId

won't work, because of hardcoded "_id" and "_type" everywhere

[metaskills]

Tell you what, I'm gonna close this ticket because I doubt that I'll be doing anything related to limit/offset or eager loading in the 2.3 branch. It's just too hard and after so much time put to the 3 version, I'm just not able to help.

Here is what I suggest. The rails 3 version is passing all tests in ActiveRecord for rails 3, tracking the 3-0-stable branch of rails, currently unreleased. So if you freeze to edge 3-0-stable rails then use the current master branch of the adapter, you should be OK.

[Excelan]

That's ok. Since there is a workaround - one can use views with required names, and this branch become obsolete, it is a clever decission to concentrate efforts on version 3 branch.

Please close the ticket.