Your Privacy Matters: We use our own and third-party cookies to improve your experience on our website. By continuing to use the website we understand that you accept their use. Cookie Policy
335
multi-part key in data used in grid - how to set the primaryKey
posted

At times, the data that I am showing in a grid comes from a result set with a 2 part key.

For example, I might be showing total qty on hand by color and size.

This allows my user to group or filter the data to provide the info that they are looking for.

But I also need to be able to select rows so that I can create a subsequent query with just the sets of colors+sizes selected.

I believe I need a primaryKey for this and for several other grid features.

How do I set the primary key to a combination of fields?

Parents
  • 460
    Verified Answer
    Offline posted

    Hello,

    I understand you’d like to use a combination of fields, like color and size, as a unique key in the Ignite UI Angular grid to enable features such as grouping, filtering, and row selection. Here’s some context on why a primary key is required and why, by default, it’s typically a single unique identifier.

    Importance of a Unique, Single Identifier as Primary Key

    In most data-driven applications, including Ignite UI Angular grid components, the primary key is designed to be a single, unique identifier. This standard is essential because it enables the grid to locate, manage, and track each row efficiently, ensuring seamless performance and data integrity. When a primary key is unique and singular, the grid can handle operations like selection, filtering, and grouping precisely, without having to manage complex combinations or check for ambiguities.

    Why the Grid Prefers Single-Field Primary Keys

    The Ignite UI Angular grid is optimized to use a single, unique field as the primaryKey. A single primary key allows the grid to quickly locate specific rows and track their state, which is essential for performance, especially with larger datasets. This approach prevents the need to recalculate unique combinations on every interaction, ensuring smooth performance and reliable data handling.

    Solution: Implementing a Composite Key for Color and Size

    To achieve the required functionality with your color and size combination, we can create a composite key by adding a new field to your data that combines these two properties. Here’s how it would work:

    1. Creating a Composite Key: In the data preparation phase, we’ll add a new field to each data item that combines the color and size values, creating a unique identifier for each row. For example, a row with color as “Red” and size as “M” would have a composite key of Red_M. This composite key can then act as the primaryKey in the grid.
    2. Setting the Composite Key as the Grid’s Primary Key: Once we add this composite key field to the data source, we can set it as the primaryKey in the grid configuration. This will enable all Ignite UI Angular grid features, including row selection, filtering, and grouping, to function with the unique color and size combination.

    Here’s an example of how this setup would look in your data and grid configuration:

    data.forEach(item => {

      item.compositeKey = `${item.color}_${item.size}`;

    });

    In the grid configuration:

    <igx-grid [data]="data" primaryKey="compositeKey" ...> </igx-grid>

    This approach still relies on the principle of a single, unique identifier. By creating a composite key field, we adhere to the primary key requirement while representing both color and size together in a unique way. It’s important to note that this solution is a workaround tailored to meet your specific needs rather than a widely practiced method. In most scenarios, using a single, pre-existing unique identifier remains the best practice to ensure optimized performance and alignment with standard data management principles.

    Conclusion

    In summary, while creating a composite field to act as a primary key can work for your requirements, it does come with some considerations. Since this is a customized approach rather than a conventional one, it may require extra steps in data preparation and maintenance, especially if the structure of color and size values changes over time.

    If this solution meets your needs, we can proceed with implementing it. However, if you have other datasets or future needs that require more flexibility, you need to work within the single, unique identifier model.

    Please let me know how you’d like to move forward, and I’m happy to assist in any way.

    Regards,

    Georgi Anastasov

    Entry Level Software Developer

    Infragistics

  • 335
    Offline posted in reply to Georgi Anastasov

    Georgi,

    Thanks for the explanation.

    But I think it would me a welcome improvement if I could specify the columns that make up a composite key.

    This would relieve me of the performance hit I would incur by traversing my data array, and side effects of adding another property to each data object.

    I believe that the grid must be traversing and hashing the data array with a single, simple, key (if specified).  So why not traverse and hash the data array in a way that assembles the composite key from the list of columns that I specify as key elements?

    I know that this question has now morphed into a feature request, and you have answered my original question, so I am marking your answer as verified.

Reply Children
No Data