Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Add NAME const for UID types #16866

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

Merged
merged 1 commit into from
Aug 11, 2022
Merged

Add NAME const for UID types #16866

merged 1 commit into from
Aug 11, 2022

Conversation

marcelsiegert
Copy link
Contributor

Documentation update for symfony/symfony#46642.

@carsonbot carsonbot added this to the 6.2 milestone Jun 11, 2022
@carsonbot carsonbot changed the title [DoctrineBridge] Add NAME const for UID types Add NAME const for UID types Jun 11, 2022
@javiereguiluz javiereguiluz added the Waiting Code Merge Docs for features pending to be merged label Jun 11, 2022
@carsonbot carsonbot modified the milestones: 6.2, next Jun 11, 2022
fabpot added a commit to symfony/symfony that referenced this pull request Jul 20, 2022
…lsiegert)

This PR was merged into the 6.2 branch.

Discussion
----------

[DoctrineBridge] Add `NAME` const for UID types

| Q             | A
| ------------- | ---
| Branch?       | 6.2
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       |
| License       | MIT
| Doc PR        | symfony/symfony-docs#16866

This allows to refer to the constant instead of an "arbitrary" string. For example:

```php
#[ORM\Column(type: UuidType::NAME)]
private $foo;
```

Doctrine [already does it this way][1] in its documentation.

The name of the constant is taken from the already existing `Symfony\Bridge\Doctrine\Tests\PropertyInfo\Fixtures\DoctrineFooType` class, where a constant with a similar purpose already exists (albeit this one is `private`). Another possibility would be `UlidType::ULID` and `UuidType::UUID` as shown in Doctrine's [Custom Mapping Types][2] documentation.

[1]: https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/reference/basic-mapping.html
[2]: https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/cookbook/custom-mapping-types.html

Commits
-------

0273fde [DoctrineBridge] Add `NAME` const for UID types
symfony-splitter pushed a commit to symfony/doctrine-bridge that referenced this pull request Jul 20, 2022
…lsiegert)

This PR was merged into the 6.2 branch.

Discussion
----------

[DoctrineBridge] Add `NAME` const for UID types

| Q             | A
| ------------- | ---
| Branch?       | 6.2
| Bug fix?      | no
| New feature?  | yes
| Deprecations? | no
| Tickets       |
| License       | MIT
| Doc PR        | symfony/symfony-docs#16866

This allows to refer to the constant instead of an "arbitrary" string. For example:

```php
#[ORM\Column(type: UuidType::NAME)]
private $foo;
```

Doctrine [already does it this way][1] in its documentation.

The name of the constant is taken from the already existing `Symfony\Bridge\Doctrine\Tests\PropertyInfo\Fixtures\DoctrineFooType` class, where a constant with a similar purpose already exists (albeit this one is `private`). Another possibility would be `UlidType::ULID` and `UuidType::UUID` as shown in Doctrine's [Custom Mapping Types][2] documentation.

[1]: https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/reference/basic-mapping.html
[2]: https://www.doctrine-project.org/projects/doctrine-orm/en/2.11/cookbook/custom-mapping-types.html

Commits
-------

0273fde6a5 [DoctrineBridge] Add `NAME` const for UID types
@xabbuh xabbuh removed the Waiting Code Merge Docs for features pending to be merged label Jul 20, 2022
@xabbuh xabbuh modified the milestones: next, 6.2 Jul 20, 2022
@javiereguiluz javiereguiluz merged commit 55b24c6 into symfony:6.2 Aug 11, 2022
@javiereguiluz
Copy link
Member

Marcel, thanks and congrats on your first Symfony Docs contribution 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants