Impossible to write a Driver thats not Illuminate

[smazurov]

Thank you so much for this package, I am glad to see a non-active record (and non-doctrine) option for Laravel. I ran into a bit of a problem:

Since Driver, needs a DB Adapter, which in turn needs QueryAdapter (all interfaces), things break down once you get to QueryAdapter. It seems like you guys cheat and just pass through directly to Laravel's Query Builder, which is wonderful if your intent is to only use Illuminate, but useless if we were to implement our own (say rethinkdb). Any plans to fix that issue?

Great stuff otherwise and I'm excited to implement this when talking to more traditional dbs.

[RemiCollin]

The Driver part is a work in progress, and yes the intent is to abstract from the Illuminate Query Builder and allow to bridge to other query builders. The goal for the QueryAdapter is to provide a a bridge between from the Illuminate interface to another query builder implementation (that's why the Illuminate QueryAdapter is a passthrough, it wouldn't make sense to write a Illuminate->Illuminate query adapter).

In your case you'd write a specific RethinkDbQueryAdapter which would be part of the RethinkDb driver package, following the QueryAdapter interface. This interface is still to define, as we have to think which minimum subset of the original QueryBuilder would be necessary to implement to talk to different Db's.

I'm working on a MongoDB driver right now, and was planning to have this done while doing the MongoQueryBuilder implementation.

But as I stated first, it's still a work in progress, and I'm totally open to suggestions on this part. Don't hesitate if you feel there's a better way to achieve this.

[devsi]

Sorry to bump an old thread, but has anything been done on this yet? I'm experiencing the same issue. We have our own DAL and to hook this up we need to write our own Driver, DbAdapter and ConnectionInterface. Unfortunately this cannot be done as Analogue hardcodes its driver to IlluminateDriver. As a work around we'll subclass Analogue and overwrite boot() so we can handle things with our own classes, but it'd be great to see something less coupled :)

Agree with @smazurov though, this is a great project. I'm so thankful for a datamapper implementation of Eloquent 👍

[RemiCollin]

The Driver was mostly implemented with the intent of integrating 3rd party DBAL based on Illuminate\Database\QueryBuilder (like https://github.com/jenssegers/laravel-mongodb) which Analogue is highly coupled to.

In theory you could build a custom query builder that interfaces with your DAL, providing you implements the subset of methods Analogue uses, and replicate how the QueryBuilder behaves.. not sure it's worth it.

I'm slowly working toward less coupling, but it takes time as the whole relationship code is based on eloquent, which is tightly coupled to the laravel database package.

[odahcam]

Using Eloquent feels like PHP <= 5.4, it simply doesn't feels like the PHP 7 way, I don't know much about Analogue, but is its idea to fill the lack of PHP 7 support from Eloquent?