Une autre question de raccordement NH Fluent

Question

J'ai un site. ce site réside dans un fuseau horaire particulier et dispose d'un type de connexion Internet spécifié. Ces deux propriétés sont stockées dans la table Site de la base de données en tant que clés étrangères d'enregistrements dans une table de recherche séparée. Je ne l'aurais jamais fait de cette façon, mais je comprends pourquoi (applique un ensemble commun de noms, donne une taille de base de données légèrement plus petite, permet des informations supplémentaires normalisées dans certains cas, et permet de récupérer facilement la liste de valeurs à utiliser comme DDL).

Je suis en train de construire un mappage qui doit inclure la récupération de cette information. Je voudrais éviter d'avoir à construire un objet de domaine et un mappage pour un champ (qui, dans certains cas, autre que l'ID de la table de recherche, tout ce qu'il y a), donc je voudrais dénormaliser la relation et juste avoir la valeur de la chaîne sur l'objet. Objectif simple.

Le problème est que la jointure que j'essaie d'utiliser suppose que la clé primaire de la table Site est référencée quelque part dans la table de recherche; en effet, nous supposons que le site est du côté «un» de la relation, ce qui est inexact. Voici les lignes cartographiques pertinentes:

Id(x=>x.Id).Column("SiteID"); 

... 

Join("lu_TimeZone", j => 
{ 
    j.KeyColumn("TimeZoneID"); 
    j.Map(x => x.TimeZone).Column("TimeZone"); 
}); 

Le SQL généré comprend la jointure:

FROM Site this_0_ 
inner join lu_TimeZone this_0_1_ 
    on this_0_.SiteID=this_0_1_.TimeZoneID 

* buzzer * Désolé, c'est incorrect, merci pour jouer. La jointure doit être:

FROM Site this_0_ 
inner join lu_TimeZone this_0_1_ 
    on this_0_.TimeZoneID=this_0_1_.TimeZoneID 

Cependant, il semble y avoir aucun moyen de dire Fluent d'utiliser le KeyColumn comme nom de colonne des deux côtés de la jointure. L'inversion du mappage pour rejoindre TimeZone to Site est irréalisable car il existe plusieurs jointures entre Site et d'autres tables de recherche.

Answer 1

Comme une épitaphe, je fini par faire une des deux choses:

• Pour les tables où il n'y avait qu'un seul champ qui pourrait jamais être intéressant, je créé un ENUM calée sur l'ID de la table et les a mappés en tant que Enums en utilisant un type personnalisé.

• Pour les tables pouvant contenir plusieurs valeurs, j'ai créé et mappé un objet de domaine.

Il peut être impossible d'obtenir le comportement d'assemblage décrit ci-dessus pour travailler sans faire référence à la sous-table comme objet de toute façon.