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.
After watching Blueprint in action on a Laracast Series, I realized a use case that could be optimized. Blueprint is all about conventions and rapid development, but this video demonstrated some confusion on when to define model
columns
as well asrelationships
. Particularly in the case ofbelongsTo
.Consider the following draft file:
In this case a user has defined what they believe to be a foreign key column, but also the
belongsTo
relationship toVenue
. While there are a few ways you may write this, ideally you would do one or the other. Personally, I would not define abelongsTo
relationship as simply defining the column is faster (less to type).For example:
However, with this PR, you may also write the following and the foreign key columns will be inferred:
As a bonus, if you were to write the original draft file, Blueprint will assume the
venue_id
is meant to be a data type ofid
.As a development note to myself and future contributors, these types of adjustments should be done in the lexer. Doing these kinds of things higher up avoid having to do it in several of the underlying generators.