Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hi Joe (and/or other maintainers)!
Love the hard work y'all are doing with this extension.
Personally, I use the Eloquent attribute autocompletion feature a lot, and I've been hacking on the extension to make it match the database schema better.
I like the type mapping refactor done in #233, but I hope I can offer a few suggestions to make it even more robust:
1. Separate cast mapping from raw type mapping
Currently, the extension maps the
attribute.cast
(from the Eloquent model) in the same way as the rawattribute.type
(from the database). But this often produces docblock types that do not match the actual PHP type.For instance, an attribute that is cast to
"datetime"
has the\\Illuminate\\Support\\Carbon
PHP type, but a MySQL table column with the raw type"datetime"
is still just astring
in PHP.So given the following
model:show
output:The extension in its current form, generates the following docblock:
But if you dump the record, it shows the actual PHP types, which are:
To solve this, I have split the list into mappings for casts and mappings for raw database types. If we fail to find a mapping for the cast, we try to map the type. This generates the following docblocks:
2. Increased the amount of supported database types
I'm sure we're not there yet, but I've gone through I think all the PostgreSQL column types and I've started on the MySQL ones.
I've used a lot more regular expressions, to group similar types, but I'm happy to break that up into a few more simple regex's if you want.
3. Return "mixed" if we don't find a mapping
Originally, when the extension failed to find a mapping, it would return the original type. This worked fine when dealing with custom casts, but not if there was no cast to begin with. The extension would then return the original raw database type as a final type. This would result in an invalid PHP type in the docblock.
Returning
"mixed"
instead means we should never generate invalid docblocks anymore.4. Don't return "mixed|null"
Since
mixed
is a standalone type, I prevent the final type from becomingmixed|null
, because that is not a valid type.