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
155●23●23●28
Hello Ness,
First, I suspect that by mentioning
Check.Id
you actually meantStore.Id
field.Second, DO.Net uses the following algorithm when building field names: first, it builds a regular
Store.Id
for theOfflineManager.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.
1) I fixed Check.Id, correct field Store.Id. 2) ok, we thought so. 3) ok, thanks.
BTW, forgot to ask: what is the advantage of not declaring
Store
field in theEmployee
class? This would simplify the things.Yes, for now we simply moved Store to Employee.
But we have found this bug just before refactoring :)
Got it.
Thanks for informing us. Will definitely fix this.