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 as relationships. Particularly in the case of belongsTo.
In this case a user has defined what they believe to be a foreign key column, but also the belongsTo relationship to Venue. While there are a few ways you may write this, ideally you would do one or the other. Personally, I would not define a belongsTo relationship as simply defining the column is faster (less to type).
For example:
models:
Conference:
name: string
venue_id: id
region_id: id
However, with this PR, you may also write the following and the foreign key columns will be inferred:
models:
Conference:
name: string
relationships:
belongsTo: Venue, Region
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 of id.
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.
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
columnsas 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
belongsTorelationship toVenue. While there are a few ways you may write this, ideally you would do one or the other. Personally, I would not define abelongsTorelationship 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_idis 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.