Level 61
For that reason I avoid any database specific features and try to stay database agnostic in my implementations since I had few projects that required database switching.
Oct 30, 2021
5
Level 15
MySQL vs. SQLite in testing
I ran into the same problem again and again in testing Laravel application.
I have some database queries where the most simplest solution is using the database built-in functions.
For example:
CONCAT(date, ' ', time)
NOW()
field REGEXP 'pattern'
These functions, and the REGEXP operator works fine under MySQL, but get error if I try to test these queries under SQLite.
I know for the NOW() I can use PHP level Carbon::now(), but not this is the point.
So is there any magic what convert the queries (functions, operators, any MySQL specific thing) to the right SQLite format? Or what is the best practice for this case?
Level 15
@bugsysha Okay, but for example how do you avoid the REGEXP operator?
Level 61
@netdjw simple. Just normalise the data. When something is created, dispatch a queued job that will extract specifics you need and populate columns that are dedicated to search you need your app to perform.
Level 61
@netdjw can't guarantee but probably in most cases REGEXP and LIKE searches are not scalable solutions.
1 like
Level 80
@netdjw If you’re writing raw, MySQL query fragments then test using a MySQL database. Don’t write MySQL-specific stuff and then act confused it doesn’t work in non-MySQL databases.
Laravel used a database abstraction layer underneath, so if you’re not using query builder methods then chances are you’re writing something database-specific and it’s not going to portable.
1 like
Please or to participate in this conversation.