Re: [Postfixadmin-devel] SF.net SVN: postfixadmin:[824] branches/postfixadmin-2.3

[Valkum <va...@go...>]

Am 26.06.2010 23:29, schrieb Christian Boltz:
> 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.
>
>   
As i know Doctrine add NOW() to all cols which are called updated or
timestamp or so on.
If Doctrine is too unspeacial for PFA the way to fo to OOP is really
useful in my eys. Writing our own DB Abstr.  layer in OOP makes the Code
cleaner and Development easier.
The Way to seperate our DB Layer from UI is so quiet simple and required
to add new technics..