gnupo

Provide a DAL to avoid cupling gnupo with any DB driver

Registered by Miguel Trias

We must have a module to hide all DB queries behind a common interface. This module has to be driver independant in order tu support all major DB driver used in PHP. I think we must not complicate this thing, maybe take another gnu DAL such as PearDB or Creole if they are up-to-date and reliable.

Assuming the user provides us the DB connection (by calling a getter or by dependency-injection for example) we must handle this connection according its type

Blueprint information

Status:
Not started
Approver:
None
Priority:
Undefined
Drafter:
None
Direction:
Needs approval
Assignee:
None
Definition:
Discussion
Series goal:
None
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

I've been thinking a little about this:

The user must construct and provide the Db-connection in runtime. For this we have the method \Gnupo\Runtime\Persistable::getDbConnection($mode).

Let the user choose any Database Access Layer (DAL) or resource type and we have a problem:
In php is not possible (afaik) to distinguish between resource types (for example a mysql_connect resource is identical to a mysqli_connect resource) so we may be tempted to think that we must support only DALs that are object-oriented (Creole, Pear::Db, DAO, etc.) but not direct connection resources.

I think we MUST avoid ANY limitation to the user that we can. This is the best desicion we can make in order to ensure that we can use Gnupo in any project later, and that Gnupo will not be suitable for certaint types of projects / environments / frameworks / users.

So I propose this:

Given an object, we can recognize the type of DAL choosed by the user by two ways:

1. The easiest for the user: At runtime we do a call to get_class() in the connection object given.
2. At parse time we look for an annotation like @Gnupo.dal. This annotation can have lots of values like "mysql", "mysqli", "Pdo", "DAO", "Creole", "Pear::Db", etc.

If we choose the (#1) we'll only support OO DAL's, the user has nothing extra to do and we should make runtime desitions (minor SQL differences, functions called etc.) probably penalising performance.

If we choose to add the annotation, then we can support DAL objects AND connection resources. Also I think this will collaborate to generate code with best performance possible.

What do You think?

(?)

Work Items

This blueprint contains Public information 
Everyone can see this information.