Combining inheritance and indexs results in build issues
0

Hi,

I had the following situation which worked fine: MyBase class inherited by MyClassA and by MyClassB. MyBase had the HierarchyRoot attribute specified without parameters thus the default ClassTable inheritance scheme.

Then in MyClassB I added two indexes on two string fields:

[Index("Field1", Unique = true, Name = "IX_F1")]
[Index("Field2", Unique = true, Name = "IX_F2")]

and it could not build anymore because of the following exception:

"Unable to build index IMyBase.FK_MyClassX.UNION.IMyBase.UNION.IMyClassB because it contains inherited fields."

Changing the HierarchyRoot inheritance scheme from ClassTable to ConcreteTable seemed to work out ok but I still feel things should work also with the ClassTable scheme.

So my question is: are we dealing with a bug here or are there e.g. conceptual reasons why I should choose the ConcreteTable in this case?

asked Jun 01 '12 at 05:50

Jos's gravatar image

Jos
44●4●5●8

edited Jun 01 '12 at 05:56

Could you please specify in what class Field1 and Field2 are declared?

(Jun 01 '12 at 06:14) Denis Krjuchkov Denis%20Krjuchkov's gravatar image

I mentioned this is in MyClassB.

(Jul 12 '12 at 04:34) Jos Jos's gravatar image

Jos, are there any interfaces used in these classes?

(Jul 16 '12 at 08:07) Dmitri Maximov Dmitri%20Maximov's gravatar image

Sorry I missed your question, yes there are interfaces.

(Aug 08 '12 at 05:32) Jos Jos's gravatar image

Maybe it is also related to this issue

(Aug 08 '12 at 05:34) Jos Jos's gravatar image
2 Answers:
oldest newest most voted
1

Hi Dmitri,

Thank you for your explanation.

So the final answer comes down to this: When using the ClassTable scheme where class X inherits from class Y and class X implements an interface with fields implemented by class Y and not by class X then DO.Net is not able to resolve this because it is not possible (for DO.Net) to bring things back together again because of the 'physical' implementation in the database.

I can live with this and work-around it and avoid problems but it also seems a bit strange to me since everything you require is available. Both data and information about how data is related and indexes can be created on the column in the table that actually contains it.

So is this something that might be fixed in the future or is it way too complex within the DO architecture to resolve this?

answered Aug 09 '12 at 06:51

Jos's gravatar image

Jos
44●4●5●8

Hello Jos,

There are some limitations in the architecture of current version of IndexBuilder, so the answer is the same as here.

(Aug 09 '12 at 07:34) Dmitri Maximov Dmitri%20Maximov's gravatar image
0

Hello Jos,

Thanks for clarification, I needed it to answer properly. The exceptions tells us that there is the following situation (simplified):

  1. ClassTable inheritance scheme is used
  2. There is persistent interface, e.g. IHasName with field string Name
  3. There is Ancestor type that has field string Name, but doesn't implements IHasName interface
  4. There is Descendant type that inherits Ancestor and implements IHasName interface inheriting its implementation from Ancestor.

As ClassTable scheme is used, the Descendant table doesn't contain column Name as it is physically located in Ancestor table. As a result, query for IHasName can't be constructed as not all implementor tables contain required columns (Name column in this case).

Hope that helps.

answered Aug 08 '12 at 07:09

Dmitri%20Maximov's gravatar image

Dmitri Maximov
2211●1●2●11
Your answer
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

about | faq | privacy | support | contact us

powered by OSQA