Properties with the same name in different child Entities

Hi,

I'm experiencing two symptoms that I think are probably related to the same problem.

1) In a Dynamic Data website, the list and edit views of some Entities do not show any values for certain columns, despite the data in those columns being valid (and in fact added through the DD "insert" web page seconds earlier).

2) In a C# console application, an attempt to read data from an Entity results in this error message:

System.Reflection.TargetInvocationException: Exception has been thrown BY the target of an invocation. ---> Mindscape.LightSpeed.LightSpeedException: Unable TO materialize FIELD [AssetID] ON TYPE [Wildscreen.Warehouse.VaultTextChangedTask]. CHECK your TABLE has an Id COLUMN AND that your mappings are correct. See INNER exception FOR details.  ---> System.FormatException: Guid should contain 32 digits WITH 4 dashes (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx).
   AT System.Guid..ctor(STRING g)
   AT(Object[] , Int32 )
   AT Mindscape.LightSpeed.Model.FieldModel.<>c__DisplayClass93.<CreateValueSetter>b__61( , Object , Object[] , Int32 )
   AT Mindscape.LightSpeed.Model.FieldModel.Materialize( , Object , Object[] , Int32& )
   --- End of inner exception stack trace ---
  

The Guid mentioned in the exception is present and correct in the database (and was created by LightSpeed seconds earlier).

I think the common pattern is that the Entities in question are children that have siblings with identical property names.

For example:

VaultTextChangedTask  and VaultMediaChangedTask are both children of VaultTask and both have a property called AssetID. I have set the column names (through the designer) to be TextAssetID and MediaAssetID respectively and the columns are created in the database with the correct names.

Should this work or do I have to use unique property names across all child Entities?

Thanks,

Chris

Yes, we do have an issue with this.  Behind the scenes, all the fields declared in a single table inheritance hierarchy basically get flattened into a single model.  So if there are two fields with the same name, LightSpeed can get the wrong one when trying to perform a mapping (it performs lookups by field name).  This is a bug, but it's not one we're likely to fix in the near future, and indeed we may choose to "fix" it by catching the problem earlier and with a more meaningful message.

There are two possible workarounds:

1. The easy workaround is to use different property names (and consequently different generated field names) throughout the hierarchy.

2. If you really want both properties to be called AssetID, there is a slightly trickier workaround.  You can name both properties AssetID, but give the underlying fields different names:

private Guid _textAssetID;
public Guid AssetID {
  get { return _textAssetID; }
  set { Set(ref _textAssetID, value); }
}

(To do this in the designer you would need to create each property with its unique name (TextAssetID or MediaAssetID), then set its Generation option to FieldOnly and write the CLR AssetID property by hand.)

Because LightSpeed maps fields, not properties, these fields will remain distinct after flattening, so the exception should go away.  But because your application code (and the Dynamic Data framework) talks to the properties, you'll be able to retain your preferred API (and Dynamic Data UI).

The bad news is that option 2 will not play nicely with some bits of the LightSpeed dynamic data library, which currently relies on the designer convention for mapping properties to underlying fields.  Specifically, the EntityDataAnnotationProvider won't work on "renamed" properties (because the LightSpeed validations are on the underlying fields, so EDAP needs to be able to figure out the field for each property).  There may also be problems if the "renamed" property is the FK of an association.  If you're keen to keep the same-name API, and these are issues for you, let us know and we will see if we can fix them.