You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A developer would like to be able to use the custom entity system to store simple key-value data, with the key being a known string ahead of time. E.g. a Content custom entity type and key values of Home, About etc. This is basically key-value storage in a similar way to a document db, and I can see the value of having this functionality. The custom entity UrlSlug property can be used as the key, but because the slug doesn't have to be unique for all custom entity types it's tricky to put an index on this table for the url slug property, and therefore we would run into scaling issues.
Some investigation is required here to think about possible applications for working in this way and whether this constitutes a better way for indexing custom entities by a string value or whether a separate key-value storage mechanism might be more appropriate (something similar to how db bound Settings work but with more flexible editing).
For now a work around is to take advantage of cached routes using GetCustomEntityRenderSummariesByDefinitionCodeQuery and then filter in code to find the correct custom entity, then use GetCustomEntityRenderSummaryByIdQuery to get more detailed info.
The text was updated successfully, but these errors were encountered:
I've added GetCustomEntityRenderSummariesByUrlSlugQuery to cover this. It simply queries the database on the url slug field and I've deferred any performance work until a bit further down the line. The api will need to work this way anyway so any performance work can be done without distrupting the api surface.
A developer would like to be able to use the custom entity system to store simple key-value data, with the key being a known string ahead of time. E.g. a Content custom entity type and key values of Home, About etc. This is basically key-value storage in a similar way to a document db, and I can see the value of having this functionality. The custom entity UrlSlug property can be used as the key, but because the slug doesn't have to be unique for all custom entity types it's tricky to put an index on this table for the url slug property, and therefore we would run into scaling issues.
Some investigation is required here to think about possible applications for working in this way and whether this constitutes a better way for indexing custom entities by a string value or whether a separate key-value storage mechanism might be more appropriate (something similar to how db bound Settings work but with more flexible editing).
For now a work around is to take advantage of cached routes using
GetCustomEntityRenderSummariesByDefinitionCodeQuery
and then filter in code to find the correct custom entity, then use GetCustomEntityRenderSummaryByIdQuery to get more detailed info.The text was updated successfully, but these errors were encountered: