Issue title: 3.0 is not easy for non string based datasources
 Issue body: I'm not sure if this is the correct place to write this so if not, just point me in the correct location.

With the 3.0 Database system, the Query is converted into sql with the sql() method and then passed into the Driver through the prepare() method.  That's fine for sql drivers but is a little weird for other drivers such as ldap.  I think the method name should be renamed.

But I would rather have the Query passed into the Driver.  For more "exotic" drivers (like csv) where you can't simply pass a string onto the underlying engine, it would be nicer to interact with the Query object instead of parsing the "sql" string.  For the normal sql drivers, they can call $query->sql() inside the prepare() method and then pass that string on to the pdo engine.

Or is there another way to implement these drivers that I'm missing in 3.0?

 Comments: 
 Comment 0: I'm willing to guess that LDAP would not support many of the Query builder features. Would an LDAP driver just ignore those query options? How would you expect an LDAP backed table object to work with DELETE queries, or queries that load associated data?

Right now the Query builder and most of the ORM really is aimed at being a really good SQL based ORM. @lorenzo and I have talked about supporting other datasources through alternative implementations of the not yet created `Repository` interface. At least that is how we planned on building support for ElasticSearch and possibly mongodb through plugins.

 Comment 1: I would expect the LDAP backend to just ignore the DELETE queries.  In the current 2.x datasources, we can pick and choose which operations we want to handle.  We can also pick and choose which options we care about.

Is there any place where I can read about the Repository interface?

 Comment 2: The ORM and Database are meant only to work with relational databases. Out of those two packages we can extract some possible generic interfaces. A LDAP plugin could consist of:
- A Repository object (having method like Table from crud operations)
- Entities, at will
- Have a Query object and QueryExpression builders (some logic can be extracted out of Database)
- Have a Connection object taking the Queries and executing them
- Have **no** driver objects

A CSV datasource can be composed with:
- A connection class (Basically something holding a reference to an SplFileObject)
- A Query class and QueryExpression builders
- Have a Connection object taking the Queries and executing them
- Have **no** driver objects

We can see that the concepts that are shared are, "Repository" "Query" and "Connection". Those objects will need interfaces extracted.

A repository interface is quite basic:

``` php

public function schema();

public function get($id);

public function find($type, $options);  

public function updateAll($query);

public function deleteAll($query);

public function save();

public function delete();

```

 Comment 3: > I would expect the LDAP backend to just ignore the DELETE queries

I know that is how 2.x worked, but that has always felt like a hack to me. Having an abstraction where 90% of the features are no-ops has always felt like a leaky and broken abstraction to me.

Having the Table class use non-relational datastores means that a huge portion of its features are basically non-functional and do nothing.

@lorenzo I think we should formalize that interface with a concrete interface. I'll add an issue for that. 

 Comment 4: @lorenzo If they don't have a driver object, does that mean that the configuration file (Config/app.php) needs to change?  Because right now, it looks like you specify a driver class for each connection.

@markstory Yes, many of the features are not used, but it allows identical usage by the consumer.  The user just has to know how to use the CakePHP model system and they can start using the custom datasources.  But I'm fine with trying to split out common code as long as the user can use the custom datasources in the same way that the user uses normal datasources.

And I think all the datasources should have something like "Table" classes and "Entity" classes.  In my custom datasource for 2.x, I have one datasource that knows how to read/write a config file.  Then I have several models for each specific file that is read/written.  Each model specifies the location of the file and the schema.  And I have beforeFind, afterFind, validation, beforeSave, and afterSave logic in these models along with behavior and relations (hasOne, hasMany).

 Comment 5: How do you guys will support MongoDB or some other database?
If ORM is tied to RDBMS strongly,  any other databases are not supported in Cake3.

I mean this "support" meaning official support. but the ORM is not able to implemented with Non SQL databases.
it would be some pain.

 Comment 6: We will provide interfaces and extract some of the common logic so that other datasources can take advantage of what we have built. Personally I don't have any interest in mongo, so I have no thought about it but I will invest some of my time in building a ElasticSearch datasource to showcase how to do that in cake 3

 Comment 7: One of the reasons we chose to focus only on RDBMS at the start was, there isn't really a good way to abstract both document based and SQL based systems under one set of code.

If we were to try and have one abstraction for both I think we would be unable to leverage either type of database very well being forced to stick to what is common. Think of the compromises we have to make with even the SQL abstractions. Those compromises would be significantly larger when trying to abstract mongo + SQL stores. I totally understand that Mongo is important for a number of people, and as the ORM stabilizes I'm hoping to test our interface theories and start building a basic mongo adapter. I think @lorenzo has similar plans for elasticsearch.

 Comment 8: RDBMS is obviously primary way. But at least Cake3 shows how to integrate NoSQL database like system into New Model. Ithink elasticsearch's shot will become it.

 Comment 9: Currently, the datasource configuration allows you to choose a different driver but forces you to use the single Connection class.  And the current Connection class is very SQL oriented.

Maybe we could change the datasource configuration to choose a Connection class instead of a Driver class.  So we would have a Cake\Database\Connection\Mysql, a Cake\Database\Connection\Postgres, etc.  And users could create their App\Database\Connection\File.

There would be a ConnectionInterface that all of them would extend.  For the built in SQL connections, they would instantiate their corresponding Driver classes and use a trait to share all their code (Cake\Database\Connection\SqlTrait).  For custom connections, a developer could either use a driver or not.  They could also provide their own custom Query object (through the newQuery method).

Thoughts?

 Comment 10: @trichins I think having a connection interface makes sense. I'd prefer to not add lots of additional connection classes, as we can get by with a single connection class. Having ConnectionManager be more general also makes sense to me.

Perhaps ConnectionManager and configuration can use the driver class to infer the connection for SQL sources. If the driver is not a SQL driver the class name could be resolved as a connection class.

 Comment 11: I was thinking more about the issues @trichins has raised. He has some good points around how the current ConnectionManager class is more than a bit limiting.

Extracting a connection interface would be very useful for adding alternate connections. I don't think having platform specific connection classes offers much. Instead I think we could solve most of the problems by changing the config options. Instead of `className` defining the driver to use, it should define the actual connection class to use. We could then add a `driverClass` config option allowing you specify the driver implementation to use in the connection. This would basically be a config option for the connection object.

 Comment 12: I'm ok with that. In what namespace should the connection manager be placed?

 Comment 13: ~~I think it is fine where it is.~~

Edit: Maybe it should live with the connection classes?

 Comment 14: In `Database` ? I don't think a general purpose connection builder should be
left in a Relational only package

On Mon, Feb 3, 2014 at 3:58 PM, Mark Story zyoung@example.org wrote:

> I think it is fine where it is.
> 
> ## 
> 
> Reply to this email directly or view it on GitHubhttps://github.com/cakephp/cakephp/issues/2617#issuecomment-33961835
> .

 Comment 15: Since the concern is around non-relational datastores does it even make sense for them to use ConnectionManager? Most SQL services have relatively expensive to build connection objects which is why we have a connection manager. However, with services like redis and ElasticSearch there isn't an expensive persistent resource to keep in the client code. Since there are no/very cheap shared resources, not sprinkling configuration around sounds like the bigger problem. To me this sounds like the kind of problem we could solve with dependency injection or other specialized service locators.

 Comment 16: I think it does make sense. You you still want features like connection aliasing for testing, for example. Connection manager is nothing but a factory used to inject the configuration to the real connection and I've always looked at it as a service locator for external sources. If we are going the way of a generic injector / service locator then I'm ok. :)

 Comment 17: A generic injection tool/container would be a pretty big change for CakePHP. If ConnectionManager was able to create arbitrary connection objects would there be any constraints on those objects?  I think we would need to add driver/connection config options or make connection objects for each of the sql databases. The current magic connection class isn't going to work if we're going to support arbitrary connection objects.

 Comment 18: This was done by extracting the RepositoryInterface

{'source': 'GithubIssues', 'repo_name_with_owner': 'cakephp/cakephp', 'issue_id': 25147741, 'repo_stars': 8565.0}