Skip to content

Add convenience method to get the identifier.#670

Merged
markstory merged 1 commit into3.nextfrom
3.1-getid
Jul 28, 2024
Merged

Add convenience method to get the identifier.#670
markstory merged 1 commit into3.nextfrom
3.1-getid

Conversation

@ADmad
Copy link
Copy Markdown
Member

@ADmad ADmad commented Jul 26, 2024

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().

@ADmad ADmad added this to the 3.next milestone Jul 26, 2024
@ADmad ADmad mentioned this pull request Jul 26, 2024
*
* @return array|string|int|null
*/
public function getIdentifier(): array|string|int|null
Copy link
Copy Markdown
Member

@dereuromark dereuromark Jul 26, 2024

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.

Copy link
Copy Markdown
Member

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 😢

Copy link
Copy Markdown
Member Author

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.

Copy link
Copy Markdown
Member

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.

Copy link
Copy Markdown
Member

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.

@markstory markstory merged commit f58ee8c into 3.next Jul 28, 2024
@markstory markstory deleted the 3.1-getid branch July 28, 2024 23:42
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants