Choosing the features based on the lowest common denominator of X number of database systems is not the right approach in implementing an ORM!
https://github.com/laravel/framework/pull/8400
This forces us to question the value of database abstraction layers and other abstraction layers in general. If one database system does not support a feature, the abstraction layer developer naturally has to omit that feature or pretend that it is supported (?!) by fake implementations. Is it OK to lose the valuable functionality for the sake of weak systems out there?
One caching system may support only one way of storing data one key at a time, and another can support batches of keys and data in one go. So, we have to omit that feature, just in case we want to switch from one to another in future, and we need “flexibility”! That sounds wrong! Plus, many developers admit that they use raw SQL or hard-coded tweaks specific to the database system they use, and do they think they have a “unplug + swap + plug + play” system?!
We have to take advantage of every single technology we use under the hood;
whether it is SQLite, MySQL, PostgreSQL;
or Memcache, Redis, AWS ElastiCache;
or Gearman, Beanstalk, RabbitMQ, AWS SQS;
or Sendmail, Postfix, Postmark, AWS SES;
or Apache, Nginx, Node.js, IIS;
or Debian, Redhat, FreeBSD, Windows…
We cannot pretend that, if we swap Beetle with Mercedes, we can drive it same way because they are both cars!
A Mercedes may not have a “proper” key to start the engine, dude!
https://en.wikipedia.org/wiki/Smart_key
Everyone comes up with an abstraction layer these days: watch out!
Happy coding..