Use Doctrine Dbal in Cake 3.0

[Cauan Cabral]

Hey guys, how about use Doctrine DBAL as an under-layer CakePHP ORM?

It have been exaustly tested, supporting many features of majors database vendors and is very flexible.

That could reduce most of necessary work at ORM layer in CakePHP 3.0 Model refactoring.

[]'s
--

Cauan Cabral
----------------

Como falar comigo: Google Talk: cau...@gmail.com Skype: CauanCabral MSN: cau...@gmail.com

Onde me encontrar:

[José Lorenzo]

I wasn't considered before when we started 3.0 because of the LGPL license. In general I would say it goes in some points against what we would like to see in a database layer API, but it is definitely a very good and complete library.

Another drawback is that we would need to wait on fies from them in case we find bugs or hope to get our changes merged in if we need a feature for our model layer.

In general I'm not extremely against it, I would like to hear others opinions.

[Cauan Cabral]

José, about license: https://github.com/doctrine/dbal/blob/master/LICENSE
It's under MIT now, like CakePHP.

[José Lorenzo Rodríguez]

I know, they changed it recently

[Steve Found]

Propel also looks quite interesting and flexible. It has an MIT licence and can be forked on github. https://github.com/propelorm/Propel

[mark_story]

There are of course downsides to using 3rd party libraries like doctrine's DBAL, and some good things too.

Bad:

* Tied to their API even when its less than exactly what we want.  While we can mess around and add more layers on top, I think that's a leaky abstraction that will only cause problems down the road.

* Installing CakePHP becomes more painful in most situations. Outside of doing a subtree merge, or embedding the doctrine source into CakePHP, installation can no longer be download/clone and go as additional dependencies will be required.

* Documentation becomes more tricky as we either end up duplicating documentation present in doctrine, or people now have 2 places to look up API methods and usage documentation.

Good:

* Warm fuzzies from integrating better with the PHP ecosystem at large.

* Theoretical reduced cost of maintenance and development as the doctrine team would largely take care of dbal.

I'm on the fence about this as I'm not overly familiar with doctrine's dbal but it is something worth considering when rebuilding the model layer as having the dbal taken care of saves some time and effort.

-Mark

[Thiago Belem]

You guys are planning use something like Composer? It would make things easier if we plan to use Doctrine.

Att.,

--
Thiago Belem
Desenvolvedor
Rio de Janeiro - RJ - Brasil

Assando Sites - Curso online de CakePHP

assando-sites.com.br

thiagobelem.net
con...@thiagobelem.net

Skype / gTalk » thiago.belem.web
LinkedIn » br.linkedin.com/in/thiagobelem/pt

[mark_story]

Yes I'm planning on getting composer integrated/used once I get some feedback on the configuration topic I started.   As configuration and application bootstrapping interwine a bit I'd like to do both at once.

-Mark

[Carlos Gant]

Great!

2012/8/29 mark_story <mark....@gmail.com>

[mark_story]

So one other gotcha with using dependencies like Doctrine DBAL is it becomes impossible to download a zip file and have a working application.  The DBAL library would exist outside of the CakePHP repo, and require people to run composer before they can really do work.

While this isn't a huge hurdle its an extra step people would need to take before they can get going.

-Mark

On Monday, 17 December 2012 17:06:26 UTC-5, Basuke Suzuki wrote:

There are of course downsides to using 3rd party libraries like doctrine's DBAL, and some good things too.

Bad:

* Tied to their API even when its less than exactly what we want.  While we can mess around and add more layers on top, I think that's a leaky abstraction that will only cause problems down the road.

As of reading of this José's post:

https://github.com/lorenzo/cakephp/wiki/3.0-Database

I think Cake's goal 3.0 can be achieved using Doctrine's DBAL without problem. Custom types, query builder, native and pdo driver supports, etc. You guys have to build ORM layer on top of the database layer, so please focus on that and use the doctrine for the layer below it. There may be almost no differences between doctrine's DBAL and your newly created database layer.

* Documentation becomes more tricky as we either end up duplicating documentation present in doctrine, or people now have 2 places to look up API methods and usage documentation.

My opinion is that beginners should not directly use the underneath functions not so casual. If you use database and you think you can't do with Cake's standard Model, maybe you are wrong. That's the way Cake will lead programmers do the right thing.

For intermediate users, they already know documentations resides in many places, not only in Cake's site, but also on custom plugin sites, Smarty sites, or even on php.net.

- Basuke

[Basuke Suzuki]

So one other gotcha with using dependencies like Doctrine DBAL is it becomes impossible to download a zip file and have a working application.  The DBAL library would exist outside of the CakePHP repo, and require people to run composer before they can really do work.

 Why do you think so? For instance, Symfony's zip file contains Doctrine in it vendor directory. You know Symfony and Doctrine are indivisual package. Symfony directory is self contained package and user can start developing right after downloading it. No need to run composer for that.

[Graham Weldon]

I think the difference here is that CakePHP is not a collection of fully separated modules (at the moment), while symfonny is a collection of distinct sub components and is packaged as a framework. As such, the framework is dependent on its parts and the release can be a collection of sub modules. Cakephp's source is maintained by the foundation as code belonging to the foundation, and including the dependency in a zip in our repo is :

- not ideal, to include a zip

- not in line With the cake software foundations contributor license agreement

Using composer is easy, but we still have a large community base that relies on the "download and go" approach to cakephp. I think it's been a successful way to build a framework, and if possible we should try and continue down this path if we can.

Cheers,

Graham 

--
Cheers,
Graham Weldon
http://grahamweldon.com
e. gra...@grahamweldon.com
p. (+61) 0407 017 293

Skype: grahamweldon

[mark_story]

True we could start creating separate zip distributions, instead of just linking to github's zipball service (which won't include dependencies). I have other reservations about using doctrine/dbal as well.  

* It duplicates a number of features that already exist in CakePHP. Caching and Events have been implemented in doctrine.

* The documentation for doctine/dbal is fairly sparse around what I feel will be important features like the query builder.  While we could contribute to help fix the documentation shortcomings, I still feel its something to take into consideration.

-Mark

[mark_story]

While I think there are some measurable advantages in using CQRS in complex applications. In simple applications it creates a measurable complexity overhead.  This overhead is justifiable when the problem/application domain is complex, but feels over-engineered for simple problems/applications.

I think making it easier to add a more complex domain model using patterns like CQRS is really valuable.  I would be concerned about it being the de-facto pattern that CakePHP requires/recommends people use though.  It can be far more complicated than many problem spaces, and require a measurable amount of glue code to wire services, command models and query models together with the storage layer.

I think there are similar separation gains to be had with fewer costs in complexity by adopting Collection/Table + Entity/Row objects as the way to build code around.  Neither of these objects should deal specifically with the storage, but instead delegate that to a persistence layer that handles persisting either an entity/collection to a given storage system.  Associations are a sticking point as you mentioned though.

-Mark

On Saturday, 5 January 2013 02:16:37 UTC-5, Patrick Leahy wrote:

I do not think it is necessary to incorporate another ORM into the CakePHP framework, nor do I feel that any better result would be obtained. When confronted with a need to refactor, using an off-the-shelf alternative is essentially the same as starting from scratch: both are inherently bad ideas.

This is not to say that major changes are not necessary (they are) or that CakePHP has a remarkably good ORM layer (it does not). It does have the ultimate practical virtue of working near enough as it ought, and presents a relatively reasonable API to the classes that utilize it. The proper type of change, therefore, is not a fresh start, but an evolutionary approach.

I recently (re-)wrote a datasource for arbitrary OAuth-enabled APIs; the process involved coming up against some rather unpleasant limitations of CakePHP's model layer. The concept of relational, SQL-speaking databases is a fairly hard dependency.

At about the same time I noted a discussion here on the topic of whether the model layer should return objects or arrays, with many adherents of both. This struck me as essentially a need for some sort of presentational logic within the model layer. Why should we not, then, have a class to format the responses from the model layer? (answer: it may not be necessary) It seems logical enough to suppose that, if MVC represents a division of types of logic within an application, that same division can be applied to each layer of the application, and perhaps to each class individually.

Unsurprisingly, my revolutionary idea had already occurred to others, and been formalized as 'Hierarchical Model-View-Controller', or 'HMVC'. Moreover there seemed to be a good number of frameworks already using this idea! Upon further examination, however, I was dismayed to see that most of these seemed to only consider the (to me) trivial case of using more than one controller for a given view. The model layer was invariably some variation on ActiveRecord.

And so I've spent a great deal of time thinking, and writing, and a little bit of time coding. All other things being equal, I would rather test ideas by experimentation rather than collective opinion. Nevertheless, I present to you the sketch of my solution to the problem of what to do with the model layer.

https://github.com/tenebrousedge/cakephp/wiki/Ideas-for-3.0

Patrick Leahy
( ten1 on #cakephp )