locked
Data Services Client fails to identify keys named Id RRS feed

  • Question

  • I'm using the WCF Data Services client with a portable model library shared between the server and client - ie I'm not using a generated client with proxy classes.

    Things work as expected, with the glaring exception that the WCF Data Services Client library does not work with keys named Id or (ClassName)Id.  The client requires keys to be named "ID", otherwise a class is not identified as an entity class.

    This is broken for several reasons - one, all the other ADO.NET libraries (EF) etc. allow the "Id" naming convention (and they also allow "ID", but don't require it).  In much of the .NET framework, "Id" is used.   Second, which types are entities are spelled out in the $metadata document/EDM model; but the client disqualifies the type anyway if it doesn't like the key name.

    Using ReSharper disassembly, I was able to examine the client code and saw that the string.EndsWith("ID") is hard-coded.

    I can't/don't want to use the attributes, b/c our model library is portable and is independent of web service/remoting concerns.

    To use the WCF Data Services client, we had to rename all our keys to "ID".

    Thursday, May 2, 2013 8:51 PM

Answers

  • Hey John,

    The functionality for the keys was added in V1 (2007). This hasn't changed at all, if we added "Id" then people might want "id" and what about other languages? The team has discussed apis that could be used to configure the metadata of client model itself. In this way you would be able to use this api to say a property is the key instead of the attributes. But this isn't something that we have current plans to do.

    I'm glad to see that you have made a voting item on this below. If this is something that many people want we can use this as indicator for the community.

    http://data.uservoice.com/forums/72027-wcf-data-services-feature-suggestions/suggestions/3679305-wcf-data-services-client-support-convention-of-i

    On the bright side we will be releasing Portable Libraries for all of our client assemblies soon. I'm not sure if this would help, but when they come out you could make your classes partial and have one file with the classes and then you can have WCF Data Services  attributes on them and have ifdef's. But this likely won't help as you likely want one set of classes not two with ifdefs.

    Thanks,

    Chris Robinson - WCF Data Services Team


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, May 3, 2013 12:10 AM
    Moderator

All replies

  • Hey John,

    The functionality for the keys was added in V1 (2007). This hasn't changed at all, if we added "Id" then people might want "id" and what about other languages? The team has discussed apis that could be used to configure the metadata of client model itself. In this way you would be able to use this api to say a property is the key instead of the attributes. But this isn't something that we have current plans to do.

    I'm glad to see that you have made a voting item on this below. If this is something that many people want we can use this as indicator for the community.

    http://data.uservoice.com/forums/72027-wcf-data-services-feature-suggestions/suggestions/3679305-wcf-data-services-client-support-convention-of-i

    On the bright side we will be releasing Portable Libraries for all of our client assemblies soon. I'm not sure if this would help, but when they come out you could make your classes partial and have one file with the classes and then you can have WCF Data Services  attributes on them and have ifdef's. But this likely won't help as you likely want one set of classes not two with ifdefs.

    Thanks,

    Chris Robinson - WCF Data Services Team


    This posting is provided "AS IS" with no warranties, and confers no rights.

    Friday, May 3, 2013 12:10 AM
    Moderator
  • Thank you for the reply Chris - it's useful to understand why things are the way they are, and I certainly appreciate the backwards-compatibility that you need to maintain.

    What about the idea that "what is a key" is a server-managed definition, and is already defined in the EDM - so the client shouldn't be making any assumptions about it, just reading the key definition from the server?  In my server-produced $metadata document, I see things like:

    <EntityType Name="User">
      <Key>
        <PropertyRef Name="ID"/>
      </Key>
      <Property Name="ID" Type="Edm.Int32" Nullable="false" p6:StoreGeneratedPattern="Identity" xmlns:p6="http://schemas.microsoft.com/ado/2009/02/edm/annotation"/>
      <Property Name="Email" Type="Edm.String" Nullable="false" MaxLength="Max" FixedLength="false" Unicode="true"/>
      <Property Name="UserName" Type="Edm.String" Nullable="false" MaxLength="40" FixedLength="false" Unicode="true"/>
    </EntityType>
    When I look at the IEdmModel on the client, the key definitions are included.  The keys are built from the EF model, which supports "Id" and also supports compound keys.  So the only effect of the EndsWith("ID") code in the client is that it prevents valid entity types from being recognized as valid entity types.

    Friday, May 3, 2013 2:03 PM