Home → Help and guidance →

FI Foreign Key Column Naming for Bi Directional HasMany broken

brandonbehrens

26 May, 2010 07:38 PM via web

Admin Functions

• Edit
• Remove

I took a look at upgrading our application to the new 1.1 release of FNH and have run into an issue where a bi directional HasMany will not set foreign key column names correctly. Automapper DOES set them correctly. I would like to know if this is a bug with the FI or if I am not doing something correctly. This worked as expected in the previous version of FNH we were using. I've attached a model and wrapper class that will reproduce the problem.

Here's a high level description of the model:

Case has a contact and an alternate contact. Both of those are just regular contact objects.
Contact has many ContactEmail and ContactPhone.
ContactEmail has a Reference back to contact.

Using the FI of 1.1, the ContactEmail table looks like this:

id
EmailAddress
Contact_id
AlternateContact_id

Previously, it was just

id
EmailAddress
Contact_id

The latter is correct and that's how it works in the old version of FNH and using Automapper in v 1.1.

Please advise.

Thanks in advance

• Entity.cs 1.9 KB
• Database.cs 1 KB

1. 2 Posted by depaulo on 02 Jun, 2010 10:10 AM

   

   1 more for this please. I am finding the same issue. When regenerating my db with 1.1 these extra fk columns are also created. I am also using classmap rather than automapper.

   Admin Functions

   • Edit
   • Split
   • Remove

2. 3 Posted by Rob Ashton on 02 Jun, 2010 01:27 PM

   

   I'm having similar issues, although with different consequences

   http://support.fluentnhibernate.org/discussions/help/169-hasmany-br...

   Admin Functions

   • Edit
   • Split
   • Remove

3. 4 Posted by Mathias Nilsson on 03 Jun, 2010 06:53 AM

   

   I'm having similar issues as well. ClassMaps that worked with 1.0 are now generating incorrect mapping files. Extra foreign keys are being created and some even for wrong tables.

   Admin Functions

   • Edit
   • Split
   • Remove

4. 5 Posted by depaulo on 06 Jul, 2010 12:30 PM

   

   Is there any extra info we can give you in relation to this issue to help track the problem down? Cheers.

   Admin Functions

   • Edit
   • Split
   • Remove

5. Support Staff 6 Posted by Paul Batum on 11 Jul, 2010 08:52 AM

   

   I've done a git bisect to determine that this issue was introduced with the
   changes related to self referential many-to-many relationships.

   I'll speak with James about it.

   Admin Functions

   • Edit
   • Remove

6. Support Staff 7 Posted by James Gregory on 23 Jul, 2010 08:53 PM

   

   Firstly, sorry for taking so long over this quite important issue.

   Secondly, if anyone wants to try updating to the latest master, there's (hopefully) a fix in place. Any feedback would be appreciated.

   Admin Functions

   • Edit
   • Remove

7. 8 Posted by Tom Reedy on 05 Oct, 2010 08:30 PM

   

   I experienced exactly the same problem with release 1.1. The latest build (694) solved that problem, but caused a new one - a References mapping on a property named differently than the property class type creates a misnamed column using the property type name rather than the property. Using the example below, the column on Serf is named "King_id" instead of "MyKing_id". I've also tried build 688 with the same result.

   public class Serf
   {
       public virtual int Id { get; set; }
       public virtual King MyKing { get; set; }
   }
   
   public class King
   {
       public virtual int Id { get; set; }
       public virtual IList<Serf> Serfs { get; set; }
   }
   
   public class SerfMap: ClassMap<Serf>
   {
       public SerfMap()
       {
           Id();
           References(m => m.MyKing);
       }
   }
   
   public class KingMap : ClassMap<King>
   {
       public KingMap()
       {
           Id();
           HasMany(x => x.Serfs);
       }
   }

   Admin Functions

   • Edit
   • Split
   • Remove

8. Support Staff 9 Posted by Paul Batum on 16 Oct, 2010 08:28 AM

   

   You can control this with conventions.

   Implement IReference convention and have it set the column name.

   On Wed, Oct 6, 2010 at 7:32 AM, Tom Reedy <
   ***@tenderapp.com<tender%***@tenderapp.com>
   > wrote:

   Admin Functions

   • Edit
   • Remove

9. 10 Posted by Tom Reedy on 21 Oct, 2010 01:44 PM

   

   Actually, when you name the property differently from the type, you get 2 reference columns in the referencing table. (From my example: MyKing_id and King_id)

   Implementing IReferenceConvention did allow me to have only 1 column based on the type. But if I wanted to base the reference on the property name, I would have to implement the IHasManyConvention, probably scanning the ChildType for matching properties to infer the name.

   Fortunately for me now, I don't have a deployed schema so I can go with the first, easier implementation. But I have a concern for the future use of Fluent: will this (or other things) change again, making it difficult to upgrade to future versions?

   Admin Functions

   • Edit
   • Split
   • Remove

10. Support Staff 11 Posted by James Gregory on 24 Oct, 2010 10:22 AM

    

    1.x versions will not contain breaking changes.

    2.x the gloves are off.

    On Thu, Oct 21, 2010 at 2:46 PM, Tom Reedy <
    ***@tenderapp.com<tender%***@tenderapp.com>
    > wrote:

    Admin Functions

    • Edit
    • Remove

11. 12 Posted by Zeda on 25 Oct, 2010 06:46 PM

    

    Have the same problem, very frustrated. I've tried to implement the IHasManyConvention to go though the childtype's properties as Tom suggested, as well as tried to implement the IAutoMappingOverride to override the automatically generated FK, none of those works. It always generates the FK_ID and MyFK_ID, which I meant to use MyFK_ID to replace the FK_ID. PLEASE HELP! I am using FH 1.1.

    Admin Functions

    • Edit
    • Split
    • Remove

12. Support Staff 13 Posted by Paul Batum on 09 Nov, 2010 12:35 PM

    

    Are you using the 1.1 release? Try a more recent build from our downloads
    page. The 1.1 release had a bug that has since been fixed. The situation
    hasn't been resolved completely but using conventions or overrides should
    work fine if you grab a recent build.

    On Tue, Oct 26, 2010 at 5:48 AM, Zeda <
    ***@tenderapp.com<tender%***@tenderapp.com>
    > wrote:

    Admin Functions

    • Edit
    • Remove