Workflow WAS Re: [Typo3-dev] DBAL - how to do it?

[Marc Güntgen]

hi all,

following this dbal-thread a few days i like to introduce a new idea to
solve your problems with supporting oracle and mssql by typo3.

actually typo3 could never be migrated to another sql-dialect than mysql.
most of the developers wouldn´t support it and it would causes endless
efforts of developement and versiontrouble.
in my opion we need a solution without changing tons of lines of code of
typo3.

goals should be:
- don´t change any existing code manually
- avoid any kind of technical risks for current users
- don´t cause any version trouble
- don´t cause licence issues
- keep freedom in our lovely community ;-)

so i suggest to parse mysql-statement at runtime and "reformat" to a
specific sql-dialect (e.g. oracle).
typo3 might be run in a mysql-emulation-environment for oracle.
it sounds naively, but think about it...

mysql uses - more-or-less - simple sql-statements.
until now mysql doesn´t support views, subselects, functions, etc.
there are no significant properitaer sql-extensions like other databases use
(especially oracle).
lets continue with oracle...

we would have a real chance to support oracle with a small emulation-
library. emulation has to process sql on syntax level. semantic analysis 
would not required.

emulation does:
- abstract datatype to specific datatypes (e.g. tinytext to varchar2)
- emulates autoincrements for primary keys
- emulates timestamps
- resolve reserved words (e.g. user to _user)
- map sql-specific functions (e.g. date conversions, string operations)
- process commits after each statment (autocommit)
- manage advanced ddl-operations (like rename column)
- map databases errors

emulation has to be include in every typo3 class and installer as common
include. all mysql-systemcalls has to been redirected to dbal. 
this can be done "generic". 
type of database has to be define during first usage of installer and could
never be changed later on.

additional i like to suggest:
- oracle has to use mysql-like, non-default sort order (CaseInSensitive,
  defined during installation).
- only one charset should be supported (no UTF-8, ISO-8859-nn).
- for quality insurance reasons: extensions should be certified by a
  DBAL-competence-team

... and at least, we might need major no changes in documentation ;-)

i think i could do this job. 

what do you think about this idea?

marc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.typo3.org/pipermail/typo3-dev/attachments/20040223/0bead3fd/attachment.htm>