-
Notifications
You must be signed in to change notification settings - Fork 28
[Proposal] Decouple MariaDB support from MySQL #870
Comments
Other targets:
|
@sisve Actually Regarding MySQL, I was preparing documentation updates about these limitations, I've also compiled a list for PostgreSQL, SQLite and MariaDB if it gets supported some day. 😄 I think that it would be Okay specifying a minimum required version and documenting possible unsupported features. Supporting MariaDB, on other hand, conflicts supporting MySQL, thus needing a decouple. If intended, a future work could be done to create separate drivers for legacy versions as suggested, something like Hibernate did. |
We're supporting both SQL Server 2005 and MySQL 5.5 to a reasonable level. That is, people can create columns of types it support, datetime is one of those types. This has happened before; see laravel/framework#18962 and laravel/framework#20465 You're welcome to suggest to drop support for these older databases, but it needs to be an explicit decision and not something that happened accidentally as a side-effect of a PR. I imagine that dropping support for a database version in the middle of a LTS release is a breaking change... |
@sisve I wasn't aware of laravel/framework#20465, good point. I've closed the laravel/framework#22000 temporarily to rebase the branch reverting this specific What about the other changes? Do you think it's reasonable to target 5.6 instead? |
I believe that splitting the grammars up into database version specific things is a good thing. If this can be done with no breaking changes I believe it can target 5.5. However ...
I'm sure you can apply the above logic to the original suggestion, MySQL vs MariaDB too. Can we automatically detect the database version when connecting to it? Do we need to query for it with something like We must always have the ability to let the user override the automatic selection and pick a grammar manually. Someone could be running SQL Server 2012, but working with a database with the SQL Server 2008 compatibility level... |
@sisve Yeah, I agree that offering legacy driver versions would be a nice idea and I also agree that legacy versions should raise exceptions for unsupported features. Picking SQL Server for instance, currently only 2 drivers would be required: one Similar work could be done for other drivers, specially for MySQL and PostgreSQL (and MariaDB if implemented). This would be a win-win for everyone. 👍 For MySQL, we could split the existing implementation in 3 drivers: Like the MySQL/MariaDB case, legacy drivers could extend from the main driver version and overload just what is needed. I think it's reasonable to let the user pick an alternate grammar manually and let the framework always use the latest features on the main driver. 😉 |
I agree this should be separated out now, while the two databases are binary compatible, so that once they diverge, the infrastructure is in place. |
PostgreSQL: SQLite: foreign-keys support was added in 3.6.19. Future features to existing drivers may add (or not) a need for a new legacy driver. For drivers providing legacy versions, it would be reasonable to provide at least (or most?) the last n previous major versions. |
SQLite:
|
I would like to revive this idea and work on a sample implementation. How do we structure the grammars? Does Or is Having the latest implementation in |
I imagine that there would be no version-less grammar, there would be a Mysql55Grammar, Mysql56Grammar (extends Mysql55Grammar), Mysql57Grammar (extends Mysql56Grammar), etc. This structure makes it every easy to figure when things are supported, and when there's a new version we just add a Mysql80Grammar. No need to take an existing version-less grammar and rename it. |
Where would you specify/configure the grammar and what would the default be? |
@sisve I see one advantage of a version-less base grammar (if we continue not requiring a minimum database version): Having a |
Currently it is possible to use the (not officially supported) MariaDB database with the MySQL driver without many issues. But this may change in the future. Also, there are some differences between them that affects existing code.
Two things that I can list are:
JSON
column type in the same way MySQL supportsNULL
andNOT NULL
on virtual columns, while MariaDB does not (and [5.3] Fix storedAs virtualAs framework#16683 fixed a MariaDB-only issue)They differ in more things that can still be implemented in Laravel and MariaDB 10.2.x started to get many behavior changes. I think it would be useful to officially support MariaDB through it's own driver (as other ORMs does) that would extend the MySQL one to reduce duplicated code. 😃
Things that differ in MariaDB would just overload the affected MySQL implementation.
I had a few further improvements ideas to
illuminate/database
that would benefit from this change.Please, let me know what you think about that. 😄
If welcome, should I target this to 5.5 or 5.6?
The text was updated successfully, but these errors were encountered: