Revert "SchemaValidator: Changing mapping of BIGINT to string|int"

[derrabus]

I'm reverting #11399 in favor of an upmerge of #11414 which gives us a more consistent developer experience across DBAL and ORM releases.

cc @ThomasLandauer

[ThomasLandauer]

So I did it in 3.1 and you did the ~same in 2.19 and now propagate/cascade/inherit it to 3.1? And this is called an upmerge? But what are "downstream projects"?

So the bottom line stays the same: This is the way to go for the future?:

#[Column(type: Types::BIGINT)]
private string|int $bigint;

[derrabus]

So I did it in 3.1 and you did the ~same in 2.19 and now propagate/cascade/inherit it to 3.1? And this is called an upmerge?

Yes, see #11416.

But what are "downstream projects"?

Your application.

So the bottom line stays the same: This is the way to go for the future?:

#[Column(type: Types::BIGINT)]
private string|int $bigint;

That would be valid, although I personally prefer this version for my projects:

#[Column(type: Types::BIGINT)]
private int $bigint;

[ThomasLandauer]

• So "downstream projects" means just "projects that are using the ORM". And "upstream projects" doesn't exist?

• #[Column(type: Types::BIGINT)]
  private int $bigint;

  => Cool - even better! :-)

[derrabus]

• So "downstream projects" means just "projects that are using the ORM". And "upstream projects" doesn't exist?

Upstream projects from the ORM's perspective would be DBAL, Persistence, Symfony VarExporter, the PHP runtime, …

=> Cool - even better! :-)

✌🏻