COmanage Developers List

[Scott Koranda <>]

> On 4/21/12 1:08 AM, Scott Koranda wrote:
> 
> >http://cakephp.lighthouseapp.com/projects/42648/tickets/873-dbo-source-assumes-queryassociation-exists
> >
> >The patch detailed there was applied and is in our source code
> >tree but it is not a complete fix. There are other places in
> >the code where checks have to be done to see if the
> >queryAssociation() method exists on the datasource.
> >
> >In hindsight I am not sure a CakePHP datasource is the right
> >approach--despite what the documentation says CakePHP assumes
> >in the core code that one is using a relational database.
> >
> >We might be better off using the Grouper Loader functionality.
> 
> Let's discuss this at the f2f. We can ask the CakePHP folks (it's
> sort of like posting to the shib lists) if we're taking an
> acceptable approach, and if so, work to provide patches to Cake.

To give you more of the flavor of this, if you look at the
datasource documentation it explains you have to write 3
auxiliarly functions and then the usual CRUD functions.

The problem is that the CakePHP code doesn't only expect CRUD.
So for example if one does

CoGroup->find('all', $params)

it will enter through your read() method, but if one does

CoGroup->findById(7)

it expects to call a query() method on the datasource and pass
it 'findById' as the $method.

So the datasource author has to implement all the findBy* and
findAllBy* interfaces.

I have implemented code to catch findById since we appear to
use that a lot, but if we should proceed we should agree to go
back to using find() with $params or to stick to a small set
of the special findBy* methods on the models.

> 
> I guess there's still a question of whether or not we should tag
> 0.5. I think we should. There's significant new functionality.
> Perhaps we should call it 0.5-alpha for the dmo.
> 

You should do what fits your needs. I will continue pushing on
the code and show you what I have.

Thanks,

Scott