"I created a class with a property that looked like this:
public List<string> AkaNames { get; set; }
This property didn't translate into anythin in the database. Either this should be translated or I should get some sort of warning or feedback indicating that it cannot be translated.
Diego's comments:
I think this is good insight, i.e. when using Code First people's expectations are naturally that we will be able to map almost anything they can put in their object model, when the reality is that the constructs and shapes that we can map are quite constrained. In the future there are different ways we can mitigate this particular scenario:
1. Recognizing this kind of property and mapping it to something appropriate: with custom O-C mapping and shadowstate it should be possible to infer a conceptual model with an entity type containing a key and a string property, then map this entity to the elements of this List<string> so that the string property is stored as the string instances and the key is kept in shadow state and/or mapped to the ordering of the elements in the list.
2. Falling back to serializing non-recognized properties or even whole objects as blobs in the database. This potion represents an important departure from the current assumption in EF that we shred objects into separate columns and only persist things that we know how to query for later.
3. Logging the decisions made by the model builder and conventions and providing a way to direct that log to the appropriate output. Not sure how we could produce warnings at design time but perhaps Roslyn will provide a way."
Having #1 or #2 or both would give us feature parity with NoSQL stores.
This item was migrated from the DevDiv work item tracking system [ID=305110].
public List<string> AkaNames { get; set; }
This property didn't translate into anythin in the database. Either this should be translated or I should get some sort of warning or feedback indicating that it cannot be translated.
Diego's comments:
I think this is good insight, i.e. when using Code First people's expectations are naturally that we will be able to map almost anything they can put in their object model, when the reality is that the constructs and shapes that we can map are quite constrained. In the future there are different ways we can mitigate this particular scenario:
1. Recognizing this kind of property and mapping it to something appropriate: with custom O-C mapping and shadowstate it should be possible to infer a conceptual model with an entity type containing a key and a string property, then map this entity to the elements of this List<string> so that the string property is stored as the string instances and the key is kept in shadow state and/or mapped to the ordering of the elements in the list.
2. Falling back to serializing non-recognized properties or even whole objects as blobs in the database. This potion represents an important departure from the current assumption in EF that we shred objects into separate columns and only persist things that we know how to query for later.
3. Logging the decisions made by the model builder and conventions and providing a way to direct that log to the appropriate output. Not sure how we could produce warnings at design time but perhaps Roslyn will provide a way."
Having #1 or #2 or both would give us feature parity with NoSQL stores.
This item was migrated from the DevDiv work item tracking system [ID=305110].