From: Matthew G. <gr...@mu...> - 2004-03-12 19:59:18
|
I was thinking more along the lines of a separate include file per DB. Each file contains all the SQL logic for the selected DB. Each SQL statement would be contained in a hash and access by a single function that is passed the key. include/lib/espsql_mysql.inc would contain something like this: $ESPSQL['admdesigner_delete_designer'] =3D "DELETE FROM ".$GLOBALS['ESPCONFIG']['designer_table']." WHERE username=3D$u AND realm=3D$r"; then accessed as: $sql =3D eval(getSQL("admdesigner_delete_designer")); On Thu, 2004-03-11 at 22:03, Ajay Patil wrote: > Dear Matthew, >=20 > I have subscribed to this list but it is my first time to post a=20 > message. I am sorry for not making any useful contribution=20 > towards PhpESP. >=20 > I have a suggestion about the switch for SQL calls for different DBS. >=20 > Perhaps, we can define all SQL calls in an properties file (or XML). > Example: > SQL_Queries.properties. > ADD_QUESTION_SQL =3D "INSERT ...." > DELETE_QUESTION_SQL =3D "DELETE ..." >=20 > The application can read the SQL queries needed from the property file. > $sql =3D getSQL("ADD_QUESTION_SQL");=20 >=20 > This approach is similar to internationalization.=20 > We can keep a separate file for each target database. >=20 > I wonder if others have a better idea. >=20 > Ajay >=20 > ----------------------------------------------------------------- > =E5=B7=AE=E5=87=BA=E4=BA=BA Matthew Gregg <gr...@mu...>=20 > =E9=80=81=E4=BF=A1=E6=97=A5=E6=99=82 2004=E5=B9=B43=E6=9C=8812=E6=97=A5= (=E9=87=91) =E5=8D=88=E5=89=8D 11:14=20 > =E5=AE=9B=E5=85=88 phpESP-devel <php...@li...>=20 > =E4=BB=B6=E5=90=8D [phpesp-dev] adodb port question.=20 >=20 > I've been slowly converting ESP over to us the ADODB[1] library > targeting mysql, postgres and sqlite as supported DB's. >=20 > I had hoped that adodb would provide enough DB abstraction that it woul= d > be possible to do the port just by replacing the native php mysql > functions and SQL bits, with adodb equivalents. I have approximately > 99% working in mysql, 70% sqlite, 10% postgres and it appears that to > get all the DB's working I will need to replace all/most SQL calls with > a function that implements a switch based on the current DB and returns > SQL appropriate for it. So my question is.. does this sound like the > path I should take? Other suggestions? >=20 > ______________________________________________________________________ > From: Matthew Gregg <gr...@mu...> > To: phpESP-devel <php...@li...> > Subject: [phpesp-dev] adodb port question. > Date: Wed, 31 Dec 1969 23:59:59 +0000 >=20 > I've been slowly converting ESP over to us the ADODB[1] library > targeting mysql, postgres and sqlite as supported DB's. >=20 > I had hoped that adodb would provide enough DB abstraction that it woul= d > be possible to do the port just by replacing the native php mysql > functions and SQL bits, with adodb equivalents. I have approximately > 99% working in mysql, 70% sqlite, 10% postgres and it appears that to > get all the DB's working I will need to replace all/most SQL calls with > a function that implements a switch based on the current DB and returns > SQL appropriate for it. So my question is.. does this sound like the > path I should take? Other suggestions? >=20 > [1] http://php.weblogs.com/ADODB --=20 mcg ------------------------------------- The IT Lab (http://www.itlab.musc.edu) |