Open SchaichAlonso opened 8 months ago
I will not add this at sure.
Currently, there is Schema::hasTable().
For indexes, I will not add something like indexIfNotExists()
or fullTextIfNotExists()
why would you do that in migrations? The current API for indexes is here, which I think is good enough for now.
I understand why you want it, in testing things around it can make sense for you, but if you look at it from the perspective of creating migrations then there is no reason for that. Why would you call indexIfNotExists()
in migrations up/down?
For being consistently ... lazy.
No way being lazy with 72920
LoC and 4190
commits 😎🔥
If there's no legitimate use case for
CREATE IF NOT EXISTS
, then there is no legitimate use case forDROP IF EXISTS
either, yet drop has a wrapper, and create does not.
This is not true, I worked on a few bigger projects (~50
migration classes), and believe me, you will need dropIfNotExists()
in the first down migration but will never need indexCreateIfNotExists()
because you must always drop things (tables, columns, indexes) if you are migrating down
and they are already dropped if you are migrating up
again.
You can still write your DDL
query manually using the DB::statement()
or DB::unprepared()
if you need more specialized SQL
query even in the migration classes.
Not every SQL statement needs to have a query/schema builder wrapper.
But we can leave this open it can be implemented in the future especially createIfNotExists()
for tables.
There is dropIfExists for tables but there is no wrapper for
CREATE TABLE IF NOT EXISTS
.Likewise, the querybuilder doesn't interface CREATE INDEX IF NOT EXISTS .