|
From: Christian B. <pos...@cb...> - 2010-06-26 21:29:16
|
Hello,
Am Samstag, 26. Juni 2010 schrieb reg9009:
> we are planning to introduce some kind of Object Relational Mapper to
> manage the database stuff. I think there were some discussions about
> it earlier. Anyway, we wanted to give Doctrine Project a final try.
> This would theoretically extend the RDBMSs support without any
> further intervention (e.g. Oracle, etc.). Any thoughts on this?
Call me an enemy of frameworks, but I don't think Doctrine or any other
database abstraction framework would be useful for postfixadmin.
We have some code in functions.inc.php to compose queries and parts of
queries (db_insert, db_update, db_delete, db_get_boolean, ... - grep for
"function db_" to get the full list) and also do the abstraction
regarding PostgreSQL vs. MySQL where needed.
I'll take db_insert as an example - you just give it the (default) table
name, an array(
'field_1' => 'value_1',
'field_2' => 'value_2',
)
and optionally an array with timestamp fields that should be set to
NOW().
The function then converts the table name[1], generates an INSERT query
from the data array (including escaping the values) and the timestamp
fields and executes the query.
Add a condition that can be used for WHERE (address = 'fo...@do...d')
and you have the parameters for db_update.
As you can see, postfixadmin already has its own database abstraction.
The main problem is that the "old" code doesn't use the db_* functions,
but at least the newer code does. Needless to say that it would be a
good idea to make the "old" code using these functions also. [5]
If I get the Doctrine documentation right [2], it does basically the
same ($conn->insert) with more code - I didn't read the framework code,
but I'm quite sure db_insert with its 10 or 15 lines of code is shorter
than the code in the framework ;-)
And (of course) Doctrine doesn't handle some things that are specific to
postfixadmin:
- the timestamp fields that are set to NOW()
- the table name conversion [1]
- escaping of all fields (except the timestamps)
That means we would need to have a wrapper to handle those things.
"Just" the framework would be a step back.
A wrapper around a framework sounds interesting[tm] - KISS anyone? ;-)
Some questions my short look at the Doctrine documentation didn't
answer:
- how are boolean values handled? (PostgreSQL uses t/f, MySQL uses 1/0)
- how is LIMIT handled? PostgreSQL has a different syntax... [3]
My vote clearly goes to using the db_* functions everywhere instead of
introducing a framework with 90% code that we never use.
Of course you can change my opinion if you have some good arguments why
the framework is better than the db_* functions. However "$framework is
cool" or "Oracle support" [4] aren't real arguments for me ;-)
Regards,
Christian Boltz
[1] $CONF['database_prefix'] and $CONF['database_tables'], conversion
is done in the table_by_key($table) function
[2] http://www.doctrine-project.org/projects/dbal/2.0/docs/
reference/data-retrieval-and-manipulation/en
(as one line)
[3] MySQL: LIMIT $fDisplay, $page_size
PostgreSQL: LIMIT $page_size OFFSET $fDisplay
I have to admit that this is hardcoded in some places - I'll
probably have to write a small db_limit function or a function to
compose SELECT queries.
In short: Every code section that checks for $CONF['database_type']
outside the db_* functions should be called a bug IMHO.
And I just found in the MySQL documentation:
"For compatibility with PostgreSQL, MySQL also supports the
LIMIT row_count OFFSET offset syntax."
Good to know ;-)
[4] I doubt people will run Oracle for their mailserver, and AFAIK
postfix doesn't support Oracle at all ;-)
[5] This should also result in merging the "create" and "edit" pages -
the only differences are the database call (insert or update) and
that one field (typically the address) has to be read-only on edit.
fetchmail.php can serve as an example how it should like.
--
Und der erste, der mich darauf hinweist, ich könne das ja selbst
umkonfigurieren, ich müsse nur die 200KB-Doku lesen, den besuche
ich zu Hause und *singe*(!) ihm den Sourcecode vor, und DAS ist
WIRKLICH eine STRAFE. [Ratti in suse-linux]
|
