We have such code:


[Serializable]
    [HierarchyRoot(InheritanceSchema = InheritanceSchema.SingleTable)]
    public abstract class Employee : Entity
    {
        [Field, Key]
        public int Id { get; set; }

    [Field]
    public string Name { get; set; }

    [Field]
    public EmployeeAccount Account { get; set; }

    [Field]
    public string Login { get; set; }

    [Field]
    public string Pass { get; set; }

    [Field]
    public int Code { get; set; }

}

public class OfflineManager : Employee { [Field] public Store Store { get; set; }

}

public class StoreManager : Employee { [Field] public Store Store { get; set; } }

public class ShopManager : Employee { [Field] public Store Store { get; set; } }

[Serializable] [HierarchyRoot] public class Store : Entity { [Field, Key] public int Id { get; set; }

    [Field]
    public string Name { get; set; }        
}

And usage:


var store = new Store();
var manager = new ShopManager();
manager.Store = store;

And we get error "constraint violation".

I think, we found the cause of this behavior.

DO makes correct table structure, but incorrect foreign keys.

Here is table:


CREATE TABLE [dbo].Employee ON [PRIMARY]

And FKs:


ALTER TABLE [dbo].[Employee]  WITH CHECK ADD  CONSTRAINT [FK_OfflineManager-Store-Store_Store] FOREIGN KEY([Store.Id])
REFERENCES [dbo].[Store] ([Id])
GO

ALTER TABLE [dbo].[Employee] WITH CHECK ADD CONSTRAINT [FK_ShopManager-Store-Store_Store] FOREIGN KEY([Store.Id]) REFERENCES [dbo].[Store] ([Id]) GO

ALTER TABLE [dbo].[Employee] WITH CHECK ADD CONSTRAINT [FK_StoreManager-Store-Store_Store] FOREIGN KEY([Store.Id]) REFERENCES [dbo].[Store] ([Id]) GO

We have [FK_OfflineManager-Store-Store_Store] on [Store.Id] field. There is no prefix on this field, but perhaps it should be so on first field.

We have next fields with prefix: [StoreManager.Store.Id], [ShopManager.Store.Id].

But in FK we see only [Store.Id], and no [StoreManager.Store.Id] or [ShopManager.Store.Id].

So we consider, that fields generating is ok and generating of foreign keys have the bag. Although I think that DO should add prefixes with class name to all fields when inheritance is SingleTable.

We were a bit confused by the lack of [OfflineManage.Store.Id] field :)

asked Jun 24 '11 at 07:08

Ness's gravatar image

Ness
155232328

edited Jun 24 '11 at 07:37

Hello Ness,

First, I suspect that by mentioning Check.Id you actually meant Store.Id field.

Second, DO.Net uses the following algorithm when building field names: first, it builds a regular Store.Id for the OfflineManager.Store field. If later a field with the same name appears from another class, like it is in your case, DO.Net prefixes the second field with the class name to avoid collision.

Third, it seems that there is a bug with foreign key construction. I'll put it in the bug fix queue. Thanks for the model, it will help to reproduce the case.

(Jun 24 '11 at 07:33) Dmitri Maximov Dmitri%20Maximov's gravatar image

1) I fixed Check.Id, correct field Store.Id. 2) ok, we thought so. 3) ok, thanks.

(Jun 24 '11 at 07:39) Ness Ness's gravatar image

BTW, forgot to ask: what is the advantage of not declaring Store field in the Employee class? This would simplify the things.

(Jun 24 '11 at 07:42) Dmitri Maximov Dmitri%20Maximov's gravatar image

Yes, for now we simply moved Store to Employee.

But we have found this bug just before refactoring :)

(Jun 29 '11 at 10:28) Ness Ness's gravatar image

Got it.

Thanks for informing us. Will definitely fix this.

(Jun 29 '11 at 10:31) Dmitri Maximov Dmitri%20Maximov's gravatar image
Be the first one to answer this question!
Please start posting your answer anonymously - your answer will be saved within the current session and published after you log in or create a new account. Please try to give a substantial answer, for discussions, please use comments and please do remember to vote (after you log in)!
toggle preview

powered by OSQA