From: Matthew G. <gr...@mu...> - 2004-03-12 21:41:31
|
Problem cases involve anywhere interactions with: auto-increment, timestamp/date, password fields and bit manipulations. I've also tried to take into consideration various ways DB's handle/represent NULL. What I've done so far is to put a adodb function or my own "wrapper" round any database specific calls to these types of functions. This appeared to work ok with mysql and sqlite. Adding postgres created some difficulties. Having done that, I think it looks cleaner to go the separate file method I've mentioned. I also think it would provide more flexibility if folks want to port to other DB's. =20 On Fri, 2004-03-12 at 15:56, Charlie Smith wrote: > Matthew: > Where I gave you a ported phpESP to Oracle with abstracted oracle > function calls, wouldn't you be able to include Oracle as one of the > supported DB's? > =20 > To answer your query about abstracting DB queries. THe idea of a hash > sounds ok. I'm not sure you'd need to have the hash for all queries.=20 > Most of the queries between MySql and Oracle work against either DB. I > noticed that ones using bit manipulation and a few that use the empty > string had to be converted, but most went straight accross. If there > is only a small subset of queries that have to be modified to work > under different DB's perhaps these could be isolated rather than > rewriting all the queries. > =20 > Are you finding that most queries require modification to run agains > all proposed DB's? >=20 > >>> "Matthew Gregg" <gr...@mu...> 03/12/04 12:48PM >>> > 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. >=20 > 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"; >=20 > then accessed as: > $sql =3D eval(getSQL("admdesigner_delete_designer")); >=20 > 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 > > ----------------------------------------------------------------- > > =C3=A5=C2=B7=C2=AE=C3=A5=E2=80=A1=C2=BA=C3=A4=C2=BA=C2=BA Matthew Gr= egg <gr...@mu...>=20 > > =C3=A9=E2=82=AC=C2=81=C3=A4=C2=BF=C2=A1=C3=A6=E2=80=94=C2=A5=C3=A6=E2= =84=A2=E2=80=9A 2004=C3=A5=C2=B9=C2=B43=C3=A6=C5=93=CB=8612=C3=A6=E2=80=94= =C2=A5 (=C3=A9=E2=80=A1=E2=80=98) =C3=A5=C2=8D=CB=86=C3=A5=E2=80=B0=C2=8D= 11:14=20 > > =C3=A5=C2=AE=E2=80=BA=C3=A5=E2=80=A6=CB=86 phpESP-devel <phpesp-deve= l...@li...>=20 > > =C3=A4=C2=BB=C2=B6=C3=A5=C2=90=C2=8D [phpesp-dev] adodb port questio= n.=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 > would > > 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 > would > > 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) >=20 >=20 >=20 > ------------------------------------------------------- > This SF.Net email is sponsored by: IBM Linux Tutorials > Free Linux tutorial presented by Daniel Robbins, President and CEO of > GenToo technologies. Learn everything from fundamentals to system > administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel --=20 mcg ------------------------------------- The IT Lab (http://www.itlab.musc.edu) |