1

So it seems SQLite does not support dropping column. I have dropped/re-added columns over the time I build my application. I changed my database to. So right now, in my migration folder, there are folders that use $table->dropColumn('someColumn'). When I use SQLite, I get an error on that line (which was explained in the link above).

This tells me that I cannot use SQLite. So I decided to use MySQL:

<?php

return [

    'fetch' => PDO::FETCH_CLASS,

    'default' => 'mysql',

    'connections' => [
        'mysql' => [
            'driver'   => 'mysql',
            'database' => ':memory:',
            'prefix'   => '',
        ]
    ]

];

But I get an error: PDOException: SQLSTATE[HY000] [2002] No such file or directory

What connection should I then use for my unit testing?

Community
  • 1
  • 1
Kousha
  • 32,871
  • 51
  • 172
  • 296
  • Can you edit into your question why not being able to use SQLite for your unit testing is a consequence of SQLite not supporting column dropping? It might help (and it is not obvious to me, though I don't know Laravel). – halfer Dec 07 '14 at 22:05
  • @halfer, SQLite yells at the line `$table->dropColumn`. That's why I can't use it because I drop columns in some migration files. – Kousha Dec 07 '14 at 22:08
  • OK, cool. Should your unit tests be taking your migration folder into account? I would have thought it would just build the database from scratch for the latest schema, rather than iterating through schema changes. – halfer Dec 07 '14 at 22:11
  • Well, I need to build my dbs. So I use `Artisan::call('migrate')` which would iterate through all schema changes. Unless there is a better way to re-create this in-memory database. – Kousha Dec 07 '14 at 22:13
  • I think that's the core of the issue - I would guess one should be able to create a database in one go, rather than as a sequence of migrations. I'd be tempted to raise a bug on this (assuming Eloquent claims to support SQLite, of course). – halfer Dec 07 '14 at 22:21
  • Looks like [someone else here](http://stackoverflow.com/a/17373639/472495) had a similar issue. – halfer Dec 07 '14 at 22:21
  • @halfer There's no issue with having multiple migrations, they're needed for deploying incremental changes to the database. SQLite's shortcomings are the problem here, not the concept of migrations. – Bogdan Dec 07 '14 at 22:31
  • @Bogdan. I'm aware what migrations are for, but it seems rather inefficient to iterate across all migrations when testing, since one presumably only wants the current schema. As I have already said, it depends on whether Laravel/Eloquent support SQLite - your comment implies that you think it is not, or that it should not be? – halfer Dec 07 '14 at 22:34
  • 1
    @halfer SQLite __is__ supported by Laravel and I was just pointing out that unlike other RDBMSs it lacks some features which make it a poor choice in this particular case. Also since the testing database is temporary, running the migrations is the only way to ensure the schema being tested against is consistent with the one currently being used in the development enviroment. – Bogdan Dec 07 '14 at 22:47

1 Answers1

1

MySQL doesn't have an in-memory feature like SQLite, so 'database' => ':memory:' won't work (short of starting a mysql server instance to write specifically in memory). Just setup a test database configuration in app/config/testing/database.php:

'mysql' => array(
    'driver'    => 'mysql',
    'host'      => 'localhost',
    'database'  => 'test_database',
    'username'  => '*******',
    'password'  => '*******',
    'charset'   => 'utf8',
    'collation' => 'utf8_unicode_ci',
    'prefix'    => '',
)

And run the migrations on setUp and reset the migrations on tearDown.

Bogdan
  • 43,166
  • 12
  • 128
  • 129