-
-
Notifications
You must be signed in to change notification settings - Fork 824
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
APIv4 - Return id_field as part of Entity.get #20457
Conversation
All entities have a unique identifier field, usually named 'id' but some entities the field is named something else. e.g. Afform uses 'name' as the identifier. This returns the name of the field as part of Entity.get, and it's also available directly from each API class e.g. Contact::getInfo().
(Standard links)
|
@@ -132,8 +132,17 @@ public static function delete($checkPermissions = TRUE) { | |||
* @return BasicReplaceAction | |||
*/ | |||
public static function replace($checkPermissions = TRUE) { | |||
return (new BasicReplaceAction(static::getEntityName(), __FUNCTION__)) | |||
return (new BasicReplaceAction(static::getEntityName(), __FUNCTION__, static::$idField)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was a bug. Tests caught it when I changed the name of the id_field
for this mock entity.
@totten with this PR you can get the id_field for any API entity directly from the API class. If you don't know the name of the class, CoreUtil::getApiClass('Contact')::getInfo()['id_field']; // returns 'id'
CoreUtil::getApiClass('Afform')::getInfo()['id_field']; // returns 'name' |
@colemanw I don't suppose this PR makes it better or worse but I do have some concerns about caching for the Entity::get data - it doesn't seem to be cached? |
No this PR doesn't affect that. |
@colemanw we added a call for it to the monolog extension because sometimes logging is called before the entity is available & it fatals - but it seems kinda expensive tbh |
FWIW, caching was also my main concern about Granted,
Additionally, note that - even with its fairly conservative usage right now - there are things like There is a parallel issue around caching the list of fields, although the status-quo is a bit different. It's already cached... Each To my eye, the entity-info and the entity-fields are very similar metadata and should follow the same lifecycle / coding-style / visibility. I guess the first question about caching is more like... how long should the cache live?
Personally, my first pick would be (c) per-request/
|
I think the performance here degrades the more extensions you have installed? Which probably pushes me to a or b Note that we use the |
Broadly this looks sensible to me and I can see how it would help. I tend to agree with Eileen re caching options |
Tests are happy, let's merge this & do caching in a separate PR. |
I don't think so... At the risk of being pedantic, my read on the trade-off (qty computations vs qty local-memory vs qty external IO calls) is that the typical resource-usage (
I suppose in some scenarios, the |
My gut agrees with you that we don't want (c) and (a)+no-prefetch have the same formulas except they trade computations versus I/O. (Surprise!) IMHO, between those, it boils down to:
|
The io is something like 2 or 3 file look ups per entity per enabled extension or module isn't it? |
I'm not seeing that with respect to Ex: Suppose you run The reason why I think caching makes sense for |
Overview
Improves APIv4 metadata so it returns the name of the unique identifier field for each entity (usually but not always named "id").
Technical Details
All entities have a unique identifier field, usually named 'id' but some entities the field is named something else. e.g. Afform uses 'name' as the identifier.
This returns the name of the field as part of
Entity.get
, and it's also available directly from each API class e.g.Contact::getInfo()
.