|
From: Christian B. <pos...@cb...> - 2010-06-27 22:45:38
|
Hello,
Am Sonntag, 27. Juni 2010 schrieb reg9009:
> Well, basically it does the same. Of course, frameworks always carry
> a lot of functionality which isn't fully used across the projects
> using the framework.
> Nowadays, the overhead generated by frameworks
> is compensated by the computing power growing continously.
Well, that were two arguments from you against using a framework *g*
BTW: I prefer to use the growing computing power to make things faster
instead of just keeping the speed ;-)
> I really like schema update stuff. The update mechanism of the
> database structure gets transparent regardless of the rdbms using
> it. Adding/removing/changing fields, indexes, etc. seems a lot
> easier for me (update.php).
OK, that _might_ be an argument. But IIRC there's also something like a
standalone "database scheme updater" part in Doctrine, so this isn't a
argument to use Doctrine in the everyday code *g*
OTOH, upgrade.php already has some abstraction included - it's just that
it isn't always used ;-) (But yes, there are really things that are
different on PostgreSQL and MySQL.)
> It's always a question of what to use and if some kind of framework
> would ease the use in general. Especially regarding data management
> I tend to go for frameworks nowadays. This also frees up some kind
> of ressources later to implement theme styles :) I would suggest we
> start and open a new branch and have a look...
I have another proposal - do it in multiple steps directly in trunk.
* Step 1: convert INSERT, UPDATE and DELETE queries to db_* calls
Switching to a database framework requires lots of work on changing how
database calls are done - we have to change all INSERT, UPDATE and
DELETE queries to use db_insert(), db_update() and db_delete.
This is something that should be done in any case, and it would also be
the base for switching to a framework (aka "no time wasted").
Target: The code should be free of UPDATE, INSERT and DELETE queries
(except inside the db_* functions of course)
(Sidenote: Ideally do this only for the edit*.php scripts and merge them
with create*.php afterwards. See fetchmail.php for an example how to do
this. The advantage is that we have 50% less code to maintain in the
future ;-)
BTW: regarding the timestamp parameters: Maybe db_update and db_insert
should know the "usual" field names ("created" and "modified" are in
nearly every table) so that the calling code does not even need to
specify them...
* Step 2: remove usage of $CONF['database_type']
After step 1, we'll only have some SELECT queries left that are database
dependent.
We should wrap those parts in functions that create (parts of) a SELECT
query - for example the LIMIT clause.
Writing a general db_select function isn't that easy because SELECT
queries can become quite interesting[tm]. However such a function could
still be useful for the 90% "simple" queries.
My first look at the Doctrine documentation didn't show me functions to
build select queries, so this also isn't wasted time.
Target: The code (except the db_* functions) should not contain any
condition based on $CONF['database_type'].
* Step 3: check if we really need the framework
We should now (after step 1 and 2) already have
- lots of db_* calls in the code instead of "hardcoded" queries
- nearly no direct db_query calls (except some complex SELECT queries)
- all database specific stuff inside the db_* functions
That's already lots of abstraction and code cleanup.
We'll then see if this is enough or if we really want/need to introduce
a framework like Doctrine.
* final notes
IMHO even with the framework we have to keep the db_* functions to do
the postfixadmin-specific work (mapping table names, timestamps etc. -
see my previous mail for details).
Within the db_* functions, we can call the framework if we decide to go
this way.
The good thing about this 3-step-proposal is (IMHO) that it can be done
directly in trunk without breaking anything. No need to fiddle with
branch handling ;-) (I can tell you some stories about that regarding
the 2.3 branch...)
> Oralce was a bad example, but e.g. sqlite.
;-)
Regards,
Christian Boltz
--
Error: File not found -- search behind couch? (Y/N)
|
