Skip to content
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

Use typed properties for default metadata #2411

Merged
merged 1 commit into from
Mar 8, 2022

Conversation

franmomu
Copy link
Contributor

@franmomu franmomu commented Feb 20, 2022

Q A
Type improvement
BC Break no
Fixed issues

Summary

I'll retarget to 2.4.x once is created.

This is kind of based on doctrine/orm#8439 and doctrine/orm#8589.

The idea is that if you use typed properties, it gets the type from that properties. For array, I've chosen hash, I thought it was more right.

@franmomu franmomu changed the base branch from 2.3.x to 2.4.x February 20, 2022 06:32
@franmomu franmomu marked this pull request as ready for review February 20, 2022 06:32
@franmomu franmomu added this to the 2.4.0 milestone Feb 20, 2022
@IonBazan
Copy link
Member

Do you think we could also add support for References and embedded documents there?

@IonBazan IonBazan mentioned this pull request Feb 20, 2022
@franmomu franmomu force-pushed the type_properties branch 5 times, most recently from 5cb2d81 to cc02d38 Compare February 20, 2022 19:11
@franmomu
Copy link
Contributor Author

Do you think we could also add support for References and embedded documents there?

Right now it sets targetDocument for EmbedOne and ReferenceOne if that's what you mean.

Copy link
Member

@IonBazan IonBazan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, I think I missed that during review 👍🏻 This looks great and good to go from my side 🚀

I'm just wondering if we need to add the changelog entry, as it could potentially introduce a BC break for people who relied on non-strict PHP type casting:

#[Field] // Will be stored in DB as `string` but casted back to `int`
private int $myProp;

which doesn't seem like a big deal though.

Copy link
Member

@malarzm malarzm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Awesome idea and job porting the feature from ORM! Two additional ideas:

  1. Do you know why ORM is not inferring nullable typed properties? I think we should do that, seems pretty straightforward, but I wonder if there are any dragons down the road.
  2. In the same vein as EmbedOne we could autocomplete collectionClass attribute for EmbedMany/ReferenceMany. I can take care of it in a follow-up PR if you'd like me to

- ``bool``: ``bool``
- ``float``: ``float``
- ``int``: ``int``
- ``string`` or any other type: ``string``
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
- ``string`` or any other type: ``string``
- ``string``: ``string``

I'd remove the "or any other type" part as this paragraph is before we teach user what types we have. Now I wrote that I think the section should be below listing all available mapping types :)

{
$type = $this->reflClass->getProperty($mapping['fieldName'])->getType();

if ($type instanceof ReflectionNamedType && ! isset($mapping['type'])) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be better to have an early return instead of a nested switch.


// float
$cm->mapField(['fieldName' => 'float']);
self::assertEquals(Type::FLOAT, $cm->getTypeOfField('float'));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

int seems to be missing compared to the list of what is autocompleted :)

@franmomu
Copy link
Contributor Author

Awesome idea and job porting the feature from ORM! Two additional ideas:

  1. Do you know why ORM is not inferring nullable typed properties? I think we should do that, seems pretty straightforward, but I wonder if there are any dragons down the road.
  2. In the same vein as EmbedOne we could autocomplete collectionClass attribute for EmbedMany/ReferenceMany. I can take care of it in a follow-up PR if you'd like me to

I'll take a look at those maybe later today, with the nullable type I remember there were some BC breaks as doctrine/orm#8723, but I haven't checked the reason.

@franmomu
Copy link
Contributor Author

I'm just wondering if we need to add the changelog entry, as it could potentially introduce a BC break for people who relied on non-strict PHP type casting:

#[Field] // Will be stored in DB as `string` but casted back to `int`
private int $myProp;

which doesn't seem like a big deal though.

Interesting! I'll add a comment for that case

@franmomu
Copy link
Contributor Author

About the nullable type property see doctrine/orm#8723 (comment)

I'm not sure if that would introduce some unwanted behaviour 🤔

@franmomu franmomu force-pushed the type_properties branch 2 times, most recently from 8afcb4d to 90600fb Compare February 22, 2022 18:38
@IonBazan
Copy link
Member

IonBazan commented Feb 23, 2022

Regarding nullable properties, I think we should leave it in current state. The behaviour in ODM is slightly different - nullable parameter decides whether to store the fields that were set to null and I would expect it to require explicit nullable: true declaration to make it store the field when using typed properties.

@franmomu franmomu force-pushed the type_properties branch 2 times, most recently from 493e765 to c04baac Compare March 5, 2022 06:45
Copy link
Member

@malarzm malarzm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As for nullable types I'd suggest to leave this PR as is and merge it once checks are passing. Then create a follow-up PR that will emit a deprecation once it detect typed nullable property that is not on par with mapping with intention to throw an exception in 3.0.

UPGRADE-2.4.md Outdated
private int $myProp;
```

This property will be stored in DB as `string` but casted back to `int`.
Copy link
Member

@malarzm malarzm Mar 6, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This property will be stored in DB as `string` but casted back to `int`.
This property will be stored in DB as `string` but casted back to `int`. Please note that at this
time, due to backward compatibility reasons, nullable type does not imply `nullable` mapping.

- ``float``: ``float``
- ``int``: ``int``
- ``string``: ``string``

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd add similar note about nullable as in upgrade docs as the behaviour is not fully intuitional

#[ODM\ReferenceMany]
public CustomCollection $referenceMany;

public static function loadMetadata(ClassMetadata $metadata): void
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just noticed: what's this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 It was copied from the ORM thinking about us having support for Static PHP Mapping, but we are not, so I'll remove it, thanks!

Copy link
Member

@malarzm malarzm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you fixing the PHPStan failure here or in a follow-up PR as it seems unrelated?

@franmomu
Copy link
Contributor Author

franmomu commented Mar 8, 2022

Are you fixing the PHPStan failure here or in a follow-up PR as it seems unrelated?

I was creating #2417 👍 to target 2.3.x

@franmomu franmomu force-pushed the type_properties branch 2 times, most recently from 23ee469 to bfa8161 Compare March 8, 2022 08:27
@malarzm malarzm merged commit e3da298 into doctrine:2.4.x Mar 8, 2022
@malarzm
Copy link
Member

malarzm commented Mar 8, 2022

Thanks @franmomu 🚀

@franmomu franmomu deleted the type_properties branch March 8, 2022 16:32
@malarzm
Copy link
Member

malarzm commented Mar 22, 2022

About the deprecation thing: https://doctrine.slack.com/archives/CAAE6T66B/p1647934766611479?thread_ts=1647885533.164609&cid=CAAE6T66B

@IonBazan some may prefer to keep these null values in DB, but some could decide to skip them and this is controlled by nullable: true/false accordingly. The name is a bit unfortunate for someone who comes from ORM background because it actually means “store null values” but that’s another story. I chose not to store my nulls in the DB on purpose.

@malarzm Actually I never used ODM in a way that I have a null in the object, not-nullable mapping, and these two factors combined end with field not being written or $unset. Frankly I thought that'd throw an exception somewhere in the reflection land

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

Successfully merging this pull request may close these issues.

3 participants