Join Adocasts Plus for $8.00/mo, or sign into your account to get access to all of our lessons.
In this lesson, we'll create our migrations, models, and some of our controllers. We'll then fill out our migrations and define our relationship's foreign key constraints.
Developer, dog lover, and burrito eater. Currently teaching AdonisJS, a fully featured NodeJS framework, and running Adocasts where I post new lessons weekly. Professionally, I work with JavaScript, .Net C#, and SQL Server.
Adocasts
Burlington, KY
Download or explore the source code for this lesson on GitHub
00:00 - Adjusting Our Users Migration
00:40 - Generating Our Migrations, Models, and Some Controllers
02:52 - Roles, Organizations, & Organization Users
04:46 - Access Levels, Difficulties, & Statuses
06:23 - Courses
07:50 - Modules
08:30 - Lessons
09:28 - Email Histories
10:15 - Organization Invites
12:02 - Password Reset Tokens
12:36 - Fixing Course, Model, Lessons Cascades
13:25 - Running Our Migrations
Join Adocasts Plus for $8.00/mo, or sign into your account to get access to all of our lessons.
Join The Discussion! (4 Comments)
Please sign in or sign up for free to join in on the dicussion.
vladimir-laskin
Hi Tom,
Thanks to your Adonis Basics course, I was able to get a live production app for our agency using Adonis JS as an API backend. I am following this course to get better at Adonis and to get familiar with Inertia.
Question: Everything worked fantastic but navigating the migrations is a pain.
Was wondering if it makes more sense to prepend the migrations based on their order like: 01_ 02_ 03_ instead of the unix timestamps.
As an example:
1750514025265_create_password_reset_tokens_table
becomes
13_create_password_reset_tokens_table
It would also make resolving migration conflicts easier, and I was wondering if there are any "gotchas" there, since I couldn't find the documentation saying anything against it
Please sign in or sign up for free to reply
tomgobich
Hi Vladimir!
That's awesome to hear, I'm happy you were able to build and get an app out to production!
As for your question, the main disadvantage comes if you're working with a team as it'll increase the possibility of merge conflicts or conflicting sorts for your migrations when merging.
Another disadvantage, though much smaller, is that you might need to constantly tweak ordering as you're working on things. For example, if you're working on commit that is adding 5 migrations (10, 11, 12, 13, 14) and you realize you need to add a new migration but it needs to run before the other 5, you'll have to reorder those existing 5. Again, that's a small issue, but using timestamps would've likely given you plenty of buffer where that wouldn't be the case.
The timestamp prefix can also be useful if you need to know when a migration was made; though you can also use the
adonis_schematable to see when the migration was run which will be similar.Apart from that, I've never tried this but I believe Lucid should handle it just fine and can't think of any other big gotchas.
Please sign in or sign up for free to reply
vladimir-laskin
Thank you for the answer, that makes a lot of sense.
Also you are right, Lucid doesn't throw any errors since I did it with numeric ordering in prod. No bugs either (hopefully, ever).
Either way, I think I will start leaving the unix timestamps. You make a great point
Please sign in or sign up for free to reply
tomgobich
Anytime, Vladimir!
That's good to know that it does work! If it works now, I'm more than sure it'll continue to work down the road 😊
Please sign in or sign up for free to reply