We just released an update that adds a new configuration option to entity and multi-entity fields.
Currently when editing an entity or multi-entity field, you have to begin typing before any values are suggested. This change will allow fields to be configured so that they show the first 25 values immediately instead (with a prompt to type to show more options).
To enable this for a particular field, right-click the field header, choose Configure Field, and look for the new checkbox at the bottom.
I imagine the “first 25” will have to be assigned to some quick-access memory allocation
What sort of performance impact does this have?
1.a. For Web UI interaction?
1.b. For ApiUser script queries / operations?
What determines the “first 25”?
2.a. Is this sorted by ID descending of that entity type?
2.a.i How would this interact with multi-type multi-entity fields: Version.entity
2.b. Perhaps is it sorted descending by created_at / updated_at datetime?
2.c. Can this be customized to something like: most used / latest updated / latest created / custom order field
At the moment I am reluctant to turn this on for any field due to limited information on what impact it will have. Is there additional technical documentation accompanying the feature?
Your first question about performance impact doesn’t have a simple answer. Well, 1.b. does: there’s no performance impact for the API because this is a UI feature to help with data input. In the API, you’re supplying the input data directly, so this feature isn’t in play. The answer to 1.a. is the more complicated one.
First off, I should mention that the “performance hit” happens once when a user opens the menu, just like when any other autocomplete is populated. The difference between when the feature is active or not is because you don’t need to type search characters that act like a filter, we’re potentially dealing with more data.
The higher the number of records that could populate the menu, the slower the menu is displayed, and the higher the potential performance impact is on the server. For example, Version.entity could point to a myriad of possible values across entity types, which all need to be looked up, ordered, and then limited to the top 25. If you had Shot.sg_sequence that had only 5 possible values, that would be super fast. We’ll generally suggest using this feature for a subset of entity or multi-entity fields that has a limited number of valid values such that it acts more like a list field but with entities. Enabling the feature on a field that has thousands of possible valid values, for example, diminishes the value as you’ll probably rarely see the entities you’re looking for and will need to type in search characters as if you hadn’t enabled the feature at all.
You should also view the performance impact through the lens of actual user interaction volume. If you’re enabling this feature on a field only visible by supervisors and infrequently used, the aggregate impact is lower than enabling it on a field frequently used by all artists.
As for what determines the first 25 (2.) it is always determined by alphabetically sorting all the possible values whether this is an entity field, multi-entity field or polymorphic multi-entity field (like Version.entity). As of this first implementation of the feature, the sorting behaviour isn’t configurable.
I don’t think we have technical documentation about the implementation of this feature, but I think the above should set you down the right path. If you have any follow-up questions, I’ll be happy to answer them.
I enjoy these updates, but I get them on every SG page I have open when working. Repeatedly.
Maybe it’s something you can prevent once the pop-up has been closed once? Or at the very least if the user has already read the message.
Sorry to hear this- it should be possible to dismiss the message and then not have it come up again. Could you get in touch with firstname.lastname@example.org and someone should be able to help you further?