Monica: Do not require all migrations on fresh installs

[vesper8]

your program sounds really unique and special and right now i can't try it yet because of a problem with is_birthday

[Illuminate\Database\QueryException]
  SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for 'is_birthday' (SQL: ALTER TABLE reminders CHANGE is_a_birthday is_birthday TINYINT(1) DEFAU
  LT 'NULL')



  [Doctrine\DBAL\Driver\PDOException]
  SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for 'is_birthday'



  [PDOException]
  SQLSTATE[42000]: Syntax error or access violation: 1067 Invalid default value for 'is_birthday'

probably to do with me using mariadb but also a result of the messy migrations.. the very extremely messy migrations.. I understand why it's like that and all.. but it's gotten out of hand IMO

at this point it would be so much simpler to tag a new version and redo the migrations with the current finished schema

most users have no problem doing a data dump.. full migrate:fresh (L5.5) and then restore their dump

and this would allow for getting rid of this complicated sets of renames and type changes and conditional this and that

you can also use https://github.com/Xethron/migrations-generator to recreate the migrations from the database itself to make the task much easier

[djaiss]

Well. The problem is Laravel really, which doesn't have what Rails has for example. I end up with a lot of migrations. And how could I solve this problem actually for current installs? If I change the migrations now, I think I'll end up with having to maintain two different paths: one for existing installations, one for newer installations.

Because while I understand that the situation is messy now, I can't really ask custom installations to do a data dump on each version. This is where I don't agree with

most users have no problem doing a data dump

I think they do actually, and that will piss them off. Or so I assume.

[vesper8]

Most github projects don't do migrations the way you're doing them and cater to fresh installs only. I personally am fine with this but I understand not everyone would be. And not all projects do it this way, some do it like you do. Still I think the next major version (0.7.0?) would be justified to have a migration cleanup. I'm not saying to do this every time, but once a year? The migrations in this project have gotten out of hand and it's actually causing a problem with new installs. I can't use your package at all because of the migration jumble. How many new users are in my situation? I read about your project, thought it was awesome, couldn't install it because of the migration problem.. tried to apply my own fix for 20 minutes.. and gave up. Why am I having this problem? I dunno.. maybe it's because I use Mariadb instead of Mysql. Whichever the reason.. your migrations are intimidating to look at, you'd probably be glad to start with a fresh slate in that regards. Doing a data dump is easy, especially if you use a package like Spatie's DB Snapshot.. then it's three artisan commands and you're done:

pa snapshot:create
pa migrate:fresh (new in 5.5)
pa snapshot:load

done in 10 seconds

Maybe consider this for your 0.7.0 release?

In any case, thanks for your hard work! I look forward to one day coming back to this package and being able to install it

[djaiss]

I agree with what you are saying. Next version will be 1.0.0 actually, so it might be a good idea to start migrations from scratch again with this release - the name 1.0.0 would be a very good candidate for this. I'll try to achieve this for this milestone.

[vesper8]

excellent! thanks! looking forward to this release, I'll keep an eye out for it