Issue: the primary key of the base table is named differently than the the key in the fk table.

Subsonic 3 does not know how to handle that, which is fine, its beta. So I was going to change the Html.ControlFor logic to just grab the table and use the pkname from that:

var fk = db.FindTable(col.ForeignKeyTo.FriendlyName);

However the .ForeignKeyTo is null. Where in the templates does that ITable get populated?


chad - did you ever resolve this ForeignKeyTo issue??

I'm in a similar position and am looking for a solution that deosn't require hacking into the Subsonic.Core implementation.




It shouldn't matter at all if the FK is named differently - what SubSonic looks for is a FK relationship - an actual CONSTRAINT in the DB. But the code you show above looks like it comes from a spike I did a long time ago - are you using

We've been out of beta for a long time :)

Rob Conery

Hi Rob,

re the ForeignKeyTo column property. I've tried this on a few projects without success (even the ubiquitous nwind test on 'Orders'). Looking at the CustomerID column on the Orders nwind db shows a null value for the ForeignKeyTo property (unless i've misunderstood the objective of that property, i was expecting it to give me a Customers ITable back from that)

what am i doing wrong?? My reason for this question was that I was trying to negate a few errors that i had run into whilst running the same bit of code from your marvelous mvc example [Html.ControlFor] and was hoping to overcome the problem that you'd obviously encountered when trying to populate the dropdown with the list of values from the foreign key table. (i.e. //TODO: I'm fully aware of the mess this is :) and I need to fix it)

phew, hopefully you get my drift!! :)


btw - using version of SubSonic.Core


I'm having the same issue as well and it's been months since this was posted. Any luck on this yet? BTW I'm using ActiveRecord.

Brian Rizzo
May I suggest simply modifying the T4 templates.Usually, I am loathe to modify a third-party library because of the commitment to bring those modifications forward into new versions of the library (should I happen to want to use a new version when it's released, which is often).But with SubSonic, it's simply the only way to address issues like this. The choices seem only to be: live with the undesirable API, modify the SubSonic templates, or choose a more flexible ORM. And because it seems the only more flexible ORM is NHibernate, I personally chose to modify the SubSonic templates.
It was easier to choose to modify the templates when I realized that the vast portion of "working" code in SubSonic is in the referenced dll, and the templates just help give me a set of model classes that access SubSonic core.Of course, the more changes I make to the templates, the more I wonder if I'm "doing it wrong." I figure the guys writing ORM's are better programmers and it sometimes seems the ORM implementers should be making some of these decisions for me.This thought weighs heavy as I get ready to alter the lazy-loading behavior in the Linq Templates.