Remove Doctrine\DBAL\Types\Type::getDefaultLength()#3255
Remove Doctrine\DBAL\Types\Type::getDefaultLength()#3255Ocramius merged 1 commit intodoctrine:developfrom
Conversation
0aad067 to
1306c3d
Compare
| */ | ||
| public function getDefaultLength(AbstractPlatform $platform) | ||
| { | ||
| return $platform->getVarcharDefaultLength(); |
There was a problem hiding this comment.
Speaking of which, why do we need to know the default type length on the platform level at all? E.g.:
dbal/lib/Doctrine/DBAL/Platforms/AbstractPlatform.php
Lines 298 to 300 in caf55ee
We're taking our hard-coded value and passing it explicitly to the field declaraion. Would it make sense to leave the length unspecified if the developer doesn't care? Otherwise, it leads to the pointless expctations like e2e0de2#diff-21fd51266275832f478e50a5b1f22748L219.
There was a problem hiding this comment.
Completely unspecified length is probably better: should be explicitly specified by developers anyway.
There was a problem hiding this comment.
How portalbe is that? From what I remember MySQL requires maximum length when declaring VARCHAR columns while PostgreSQL doesn't.
There was a problem hiding this comment.
There are two points here:
- If a platform doesn't require max length (PostgreSQL), DBAL shouldn't require max length either but it shouldn't provide any hard-coded length in DDL. It should omit it.
- If a platform does require MySQL, DBAL should require it in the column definition but it shouldn't provide any hard-coded length in DDL. It should fail.
This way, if you use only one platform (PostgreSQL) and don't care about portability, you can omit the length and use DBAL w/o any artificial restrictions. Otherwise, you have to explicitly specify the length. It's not the DBAL's job to specify it for you.
Summary
Not used by DBAL itself, only overridden by StringType. Some other types (DateIntervalType) hardcode limits in
getSQLDeclaration()directly.1st step towards #2841 (Refactoring type system).