Stop relying on Type::__toString#2835
Conversation
| use Doctrine\DBAL\Event\SchemaAlterTableAddColumnEventArgs; | ||
| use Doctrine\DBAL\Event\SchemaAlterTableRemoveColumnEventArgs; | ||
| use Doctrine\DBAL\Event\SchemaAlterTableChangeColumnEventArgs; | ||
| use Doctrine\DBAL\Event\SchemaAlterTableRenameColumnEventArgs; |
There was a problem hiding this comment.
I reordered the use statements. Is it good or did the previous order have some meaning I should keep?
There was a problem hiding this comment.
No worries on reordering it, I usually do it on a separated commit to make it easier for people to review stuff 😄
There was a problem hiding this comment.
Yeah, I got lazy there, I'll do that.
2fe3fd6 to
e291f88
Compare
| $type = $field['type']; | ||
| if ($type instanceof Types\IntegerType || | ||
| $type instanceof Types\BigIntType || | ||
| $type instanceof Types\SmallIntType |
There was a problem hiding this comment.
Should I introduce a parent class? This test is done several time ( it done in SQLServerPlatform, for instance)
There was a problem hiding this comment.
Or maybe a marker interface?
There was a problem hiding this comment.
Do you mean something like an AbstractNumberType? It wouldn't introduce number-specific functionality and just be an empty class, if you meant such a solution. A marker interface would have no methods, right? I'm not sure about new class or interface files, that are only introduced for checks. Do those have a purpose in userland for custom types or would those be only used internally?
I also considered (static?) methods for internal type checking, but those had to be maintained too and aren't elegant either. It's like we can only introduce more complexity to Doctrine.
There was a problem hiding this comment.
Do you mean something like an AbstractNumberType? It wouldn't introduce number-specific functionality and just be an empty class, if you meant such a solution.
Correct, but indeed, an interface is better
A marker interface would have no methods, right?
yup
I'm not sure about new class or interface files, that are only introduced for checks. Do those have a purpose in userland for custom types or would those be only used internally?
People that introduce numeric types and would like to benefit from the code behind those checks could implement that interface, so yeah, there is a purpose in userland.
I also considered (static?) methods for internal type checking, but those had to be maintained too and aren't elegant either. It's like we can only introduce more complexity to Doctrine.
Yeah, and I think a marker interface is really not a big thing to make public.
There was a problem hiding this comment.
👍 for the marker interface. I'd suggest to mark it as internal to tell people to simply no use it (@internal).
| ) { | ||
| $default = " DEFAULT ".$field['default']; | ||
| } elseif (in_array((string) $field['type'], ['DateTime', 'DateTimeTz']) && $field['default'] == $this->getCurrentTimestampSQL()) { | ||
| } elseif (($type instanceof Types\DateTimeType || $type instanceof Types\DateTimeTzType) |
There was a problem hiding this comment.
Indeed, and we probably should have added the immutable type here as well
There was a problem hiding this comment.
@lcobucci the immutable type extends the mutable type, so it's already ok :)
ed1e052 to
9008fdf
Compare
b5ea715 to
eb705ad
Compare
|
The build fix was just to check I didn't actually break things. I will remove them when the PR looks like it's mergeable. |
|
Also, please see #2838 for a quick fix of the build until you find a better solution if there is one. |
eb705ad to
6131a51
Compare
| } elseif ((string) $field['type'] == 'Date' && $field['default'] == $this->getCurrentDateSQL()) { | ||
| $default = " DEFAULT ".$this->getCurrentDateSQL(); | ||
| } elseif ((string) $field['type'] == 'Boolean') { | ||
| } elseif ($type instanceof Types\DateType && $field['default'] == $this->getCurrentDateSQL()) { |
There was a problem hiding this comment.
Maybe I should name the marker interface differently because of Types\DateType does not implement it although it does map to a PHP \DateTimeInterface instance? Suggestions?
|
@lcobucci please review again. I kept the build-fixing commit to ensure I did not break anything. |
How about merging #2838 right now and do it your way later? That would make things easier for all the outstanding PRs... |
Majkl578
left a comment
There was a problem hiding this comment.
Needs some tests, as you can see, Travis is green even though there's a fatal error. :/
| $default = " DEFAULT ".$this->getCurrentDateSQL(); | ||
| } elseif ((string) $field['type'] == 'Boolean') { | ||
| } elseif ($type instanceof Types\DateType && $field['default'] == $this->getCurrentDateSQL()) { | ||
| $default = " DEFAULT ".$this>getCurrentDateSQL(); |
There was a problem hiding this comment.
Nice one (accidentaly removed -), one would say it would fatal right away, but it won't, only when executed... PHP...
There was a problem hiding this comment.
Really good eyes here. I didn't saw that too. 👍
There was a problem hiding this comment.
I got very unlucky, that's the only if that was not covered.
6131a51 to
c65275b
Compare
|
I created #2851 to prove the test work with the previous code. Please review and merge it, and I shall rebase this. |
|
Oh snap I need to add #2838 to it if I want to prove anything |
c65275b to
2cdc601
Compare
|
Related issue in ORM: doctrine/orm#5760 |
It groups things naturally.
It is a somewhat fragile thing to do.
2cdc601 to
9e75bb0
Compare
|
🚢 |
|
Please don't review again then :P |
|
|
||
| namespace Doctrine\DBAL\Types; | ||
|
|
||
| use Doctrine\DBAL\Platforms\AbstractPlatform; |
There was a problem hiding this comment.
What was the point for this use statement?
|
|
||
| namespace Doctrine\DBAL\Types; | ||
|
|
||
| use Doctrine\DBAL\Platforms\AbstractPlatform; |
There was a problem hiding this comment.
What was the point for this use statement?
It is a somewhat fragile thing to do.