Question

Our company is in the process of reviewing different ORMS for the rewrite of our legacy sytem, as such we have decided that DO.NET is the route we are going to take.

If i have a Company entity with the following structure

    [HierarchyRoot]
public class Company : Entity
{
    [Key, Field]
    public int Id { get; set; }
    [Field]
    public string Name { get; set; }
    [Field]
    [Association(OnOwnerRemove = OnRemoveAction.Cascade, OnTargetRemove = OnRemoveAction.Deny)]
    public EntitySet<Address> Addresses { get; set; }

    public Company()
        : base()
    {
    }

    public Company(Session session)
        : base(session)
    {
    }
}

[HierarchyRoot]
public class Address : Entity
{
    [Key, Field]
    public int Id { get; set; }
    public string Line1 { get; set; }

    public Address()
        : base()
    {
    }

    public Address(Session session)
        : base(session)
    {
    }
}

i see the table that gets generated for this association is Company-Addresses-Address is there anyway to override this naming convention to something like CompanyAddresses

Regards

Answer 1

0

I'm not member of DO team but our company uses DO for almost two years, so I'll make a brief comment, maybe it will help you.

In your case DO will generate many-to-many association because there is no reference to Company in Address. If you add field Company to Address and write PairTo in Address association you will receive one-to-many association, one Company - many addresses.

And in this case additional table will not be generated, only foreign key in Address table will.

answered Jul 12 '12 at 11:23

Ness
155●23●23●28

Hi, thanks for the comment however I am not concerned with the actual new table generated. I do not want a new key added to address I want to be able to change the naming convention of the lookup table that gets generated (Company-Addresses-Address) is pretty horrendous.

(Jul 13 '12 at 02:15) semaphore

Answer 2

Hello semaphore,

Sorry for the delay.

Unfortunately, there is no way to intercept the naming logic for now. This might be available in the future versions only.

However, there is an option to declare an intermediate class, say, CompanyAddress, which will contain 2 fields (Company & Address, both of them might be primary fields) and act as a link between Company and Address types.

Hope that helps.

Subscription:

Related questions