[5.6] Make migration from convenient naming conventions #20760
Conversation
tillkruss
changed the title
|
I love how you snuck the StudlyCase thing into this PR. 👍 all around. |
|
👍🏻 |
|
|
||
| /** | ||
| * Ensure that a migration with the given name doesn't already exist. | ||
| * Ensure that a migration with the given name does not already exist. |
There was a problem hiding this comment.
Because typically contractions are used in conversational English and avoided in formal writing. But it's not a big deal, seems like a nit-picky thing to do.
There was a problem hiding this comment.
I've never met a technical writer that dislikes contractions being used.
There was a problem hiding this comment.
Even if that were the case, why change it in this PR? Make a separate PR for it
There was a problem hiding this comment.
He wrote and rewrote a bunch of comments in this PR. Are you seriously that offended by it?
There was a problem hiding this comment.
I'm not saying it's right or wrong. Nor that it needs to be changed or not. I was simply adding to the idea of "formal writing" that I have yet (in like 6 years of working with technical writers) met one that dislikes their use. Which means, it can't be that informal if few who write professionally in the tech industry seems to really care in either direction.
There was a problem hiding this comment.
I'm not offended by anything? I'm just saying it's a useless change and not really in the scope of this PR
There was a problem hiding this comment.
This is a trivial change. Honestly one that was either automated by my IDE or I did inadvertently when reviewing comments. Glad to revert it if additional changes are required for this PR.
|
Would it be ok if I created some code for renaming/dropping/etc foreign keys and indexes? I have hundreds of migrations that do that and having something like remove_fk_AAA_from_BBB and rename_index_999_to_index_888_in_XXX would be nice. |
|
@fabiolrs For sure. However, given the delay in merging this - I may break this out into its own package. If this gets merged into core, great. If not, then a package seems a good direction. |
GrahamCampbell
changed the title
|
I don't think I want to maintain this in the core. |
|
@jasonmccreary Did you end up creating that package? |
|
It would seem these new additions have ended up in no mans land. To @taylorotwell's point, they understandably bring too much overhead to core. However, given their nature - leveraging the core I may see if they are welcome additions to @JeffreyWay's generators package. Either way, I have opened #22648 with hopes the |
10 participants
This expands upon the recently added naming convention of
create_XXX_tableby also allowing the following convenient naming conventions:The
_tablesuffix is optional. If provided it will remain in the migration and class names, but automatically removed from the table name.I'll admit this implementation is naive. I took care to minimize impact on existing classes and methods. However, if well received by the community, the code could be greatly streamlined by removing the
tableandcreateoptions and refining these conventions to support column data types.This also includes a small change to allow the developer to use a
StudlyCasemigration name in an effort to unify conventions with other artisan commands.