[BUGFIX] Added migration to set columns last_login and last_login_source...

[skarp2]

... columns as nullable. Must use raw queries to achieve this, so perhaps create conditionals to cater for other supported storage methods.

Solves this bug: Failing to install #333 and also an unreported bug when creating a user in back end.

This is the unreported bug that is fixed: When adding new user from back end: URI: /configuration/user/new-user

Exception message:
SQLSTATE[HY000]: General error: 1364 Field 'last_login' doesn't have a default value (SQL: insert into `seat_users` (`email`, `username`, `password`, `activated`, `updated_at`, `created_at`) values (email@address.com, username, KEY-HASH-HERE, 1, 2015-02-05 21:31:37, 2015-02-05 21:31:37))

Caveats

• If application is installed with a data storage that does not support the SQL syntax, the migration will fail

  Why this solution anyway

• IMO the correct value when a user has not logged in is NULL. This is better than putting some fictitious information like

$user->last_login = new \DateTime;

• The same goes for _last_loginsource: The user has never logged in, so why put a value like "127.0.0.1"?
• If people are using unsupported storage methods, they should get an error when running that migration. This so they can add conditionals to the file to add raw query for their storage type
• The problems will be manageable - few migration files will probably ever use raw queries.

  Alternative fix

Modify the User model; if last_login and last_login_source is not set, then add the following default values;

• last_login = 0000-00-00 00:00:00
• last_login_source = 0.0.0.0

[skarp2]

I now see that

DB::raw() 

is used extensively in the application. app/controllers folder has 73 occurrences. This means that this fix is absolutely the correct one, in my opinion, because the application is committed to SQL syntax anyway.

[eve-seat]

MySQL (and probably MariaDB) are the only supported DB's atm. This fix is ok for that ;)