Unplanned
Last Updated: 02 Jul 2020 09:46 by ADMIN
Patrick
Created on: 29 Nov 2012 11:36
Category: Data Source
Type: Feature Request
70
Support composite keys in the DataSource ID property
At the moment, the DataSource only uses one field for its ID property (if you enter several, then only one is used, apparently).  This doesn't reflect reality, in that in many cases (where one record is a child of another), the key field for a database table is a composite (from 2 or more fields).  
The existing situation causes problems in inline editing of the KendoUI grid, because default values need to be set for foreign key fields, but if these are set to a valid value, then spurious calls to the Inline_Create method occur because the DataSource treats the record as a new record when it is not.
In any case, allowing multiple fields would simply reflect reality.
9 comments
ADMIN
Nikolay
Posted on: 02 Jul 2020 09:46

Hello Kevin,

This feature is currently not planned for a release. However, once it gets placed in the RoadMap it will receive a status Planned and later on Completed when it is live.

Addityioanlly, you can click on the Follow button to receive automatic updates about status changes.

Regards,
Nikolay
Progress Telerik

Progress is here for your business, like always. Read more about the measures we are taking to ensure business continuity and help fight the COVID-19 pandemic.
Our thoughts here at Progress are with those affected by the outbreak.
kevin
Posted on: 25 Jun 2020 19:00
How can I track the release of this feature request? 
Asiri Dissa
Posted on: 03 Jun 2020 02:35
Still not in place?
This is a valuable addition to the framework. Hope you are working on this.
ADMIN
Nikolay
Posted on: 24 Dec 2019 12:53

Hi Alexander,

Thank you for bringing this feature request back to our attention. I can definitely see the value in it so I uplifted its priority and it will be reviewed by the Product Management for future planning and implementation.

    Regards,
    Nikolay
    Progress Telerik

    Get quickly onboarded and successful with your Telerik and/or Kendo UI products with the Virtual Classroom free technical training, available to all active customers. Learn More.
    Alexander
    Posted on: 18 Dec 2019 02:26

    I use Kendo with a SQL data warehouse with a normalised star schema design in order to achieve scalable performance and parallel operation. This uses large sets of fields as a primary key so the suggested workaround of creating a psuedo key by concatenating just wouldn't be feasible.

    The only workaround for this design is to include a separate ID field for use only with Kendo. This destroys performance and has forced us to avoid using Kendo for CRUD operations whenever possible.

    I think it's about time composite keys were supported so this can be a true option for use with enterprise grade applications.

    Stephen
    Posted on: 02 Apr 2019 14:12
    I am surprised that a professional and enterprise-strength toolset like this product still does not support composite keys after all these years. Let's make it happen! :)
    Steve
    Posted on: 19 Feb 2018 17:22
    I worked around this with a pseudo key as suggested in this post. https://www.telerik.com/forums/composite-datakey-in-kendo-ui-mvc#JlhcEtSyAEqMWaW6TjnDKQ
    Patrick
    Posted on: 23 Aug 2014 19:45
    I have used the following workaround to solve this. 
    Usually I have to use buddy or ViewModel classes in the grid, rather than the raw entity framework (or other) classes from the database itself, because the raw classes usually have circular object graphs (because they have parent child relationship fields). 
    
    In the code to create buddy/viewmodel classes from the raw classes, I populate an extra field that I've added to the buddy classes, IDForKendoTemplate, and I give this a unique value (i.e. 1, 2, 3, sequentially) for each object that is converted.  I can then use that field as the ID for kendoUI grids, and to identify parent grids uniquely in templates.
    Kevin
    Posted on: 15 May 2013 21:53
    I ran into this too.  A UI framework shouldn't really force us to have our data stored in a certain way to be effective.