-
Notifications
You must be signed in to change notification settings - Fork 100
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
Add convenience method to get the identifier. #670
Conversation
* | ||
* @return array|string|int|null | ||
*/ | ||
public function getIdentifier(): array|string|int|null |
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.
The one not so nice thing about such a generic api is that array|scalar is always an issue for any app usage, in regards to developer or static analyzers.
Would be nice if there was a more concrete API to either get scalar or not, I always end up having to inline annotate everything that has such an API
- getScalarIdentifier()
- getArrayIdentifier() / getCompositeIdentifier()
etc as idea.
But I guess that is out of scope here. So no objections from me, just this remark.
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.
The array
part of this type is the problem imo. We've inherited that from the ORM though because we need to support composite primary keys 😢
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.
Yeah the returns types are due to the possible pK values types. Addressing that would be a separate issue.
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.
Well, there is an option to separate here as by my proposal, throwing exception in the other case.
Removing the need to delegate this check to the consumer.
But as mentioned, nothing that is important at this point. Just a though.
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.
If we did narrow types here wouldn't we be left with partial support for composite primary keys? While the types are a bit annoying, I'd rather we have consistent support for composite primary keys over ergonomic types in one method.
If you just need that id/identifier then using this new method would be more convenient than doing
$this->Authentication->getIdentityData('id')
(which can throw an exception) or doing$this->Authentication->getIdentity()?->getIdentifier()
.