I’ve been struggling to try and get Data Services to work with the new LightSwitch 2.0 OData Data Source.
Noticing that OData 3.0 is still not supported I had to fall back to 2.0 version.
It happens that my Data Context is nothing but wrapper over some xml serialized object to enable OData access.
This “magic” happens using the Reflection Provider and it works fine regarding all the CRUD operations.
The problems start when I try to use this service in LightSwitch, and realize that all my entity associations are wrong.
The situation I have is exactly the same as if you look at Microsoft’s sample code.
So, using this data model:
[DataServiceKeyAttribute("OrderId")]
public class Order
{
public int OrderId { get; set; }
public string Customer { get; set; }
public IList<Item> Items { get; set; }
}
[DataServiceKeyAttribute("Product")]
public class Item
{
public string Product { get; set; }
public int Quantity { get; set; }
}
It’s obvious the “one-to-many” relationship between Order [1 – *] Items.
But looking at the xml metadata of this service, the association is declared as “many-to-many”:
<Association Name="Order_Items">
<End Type="WEBfactory.StreamInsight.Adapters.Carel.DataServices.Order" Multiplicity="*" Role="Order"/>
<End Type="WEBfactory.StreamInsight.Adapters.Carel.DataServices.Item" Multiplicity="*" Role="Items"/>
</Association>
Now, this doesn’t really bother much when using a “Service Reference” client, but since LightSwitch doesn’t support “many-to-many” relationships I always get a warning when trying consume this service and the relations are neither imported, nor possible to manually define.
Does anyone have a clue how to work enforce a relationship type using the Reflection Provider?
Thanks!!
The relationship between Order and Item in this case actually is many:many – if it were 1:many as you propose, an Item could only be in one Order.
That said, you can create the 1:* relationship by adding a corresponding property to the Item class:
That results in the following $metadata, which may or may not cause the same problem:
This is likely a limitation of the Reflection provider (I’ll edit this answer if it turns out not to be), so the only workarounds today are to use either the EF provider or a custom provider.