Menu
▾
▴
phpesp-devel
|
From: Charlie S. <Sm...@ld...> - 2003-09-29 14:25:14
|
Where is the API located for PEAR? Could the work I'm doing on an OCI8 (Oracle) rewrite go to help in an = effort to port to PEAR compliant DB? I've a question with regards to how the NOT NULL default '' fields would be= = defined in the PEAR description? I'd be inclined to define these types of fieds as NOT NULL in Oracle and le= t= the code or a trigger fill in the value with something if needed. Any opinions? I'm sorry, I'm not familiar with the PEAR API. Is this just a supporting = library of php code? >>> "Jeremy Buchmann" <je...@we...> 09/25/03 11:29AM >>> Hi all, I'm evaluating the use of phpESP for my company and have a few quick=20 questions. =46irst, we use PostgreSQL for all our database needs. Since phpESP uses=20 mySQL, we would either have to port it to PostgreSQL or assist in the=20 port to PEAR. I'm experienced in PHP/PostgreSQL, and I think based on=20 the number of lines in the code base that have 'mysql' in them, that I=20 could do a port to PostgreSQL in 1-2 weeks. I'd rather not fork from=20 the main distribution, so ideally I'd like to help in the port to PEAR,=20 but I've never used PEAR. With a quick glance at the API, it looks=20 easy enough...fairly similar to Perl's DBI. So my questions are, how=20 is the PEAR port coming along? Would my help be welcome and useful? =20 Would phpESP only use the database parts of PEAR? Thanks, Jeremy ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf=20 _______________________________________________ phpESP-devel mailing list php...@li...=20 https://lists.sourceforge.net/lists/listinfo/phpesp-devel=20 ---------------------------------------------------------------------------= --- This message may contain confidential information, and is intended only for= = the use of the individual(s) to whom it is addressed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D |
|
From: Charlie S. <Sm...@ld...> - 2003-09-30 14:28:31
|
Looks like Jeremy Buchmann and I (Charlie Smith) could work on the PEAR por= t= right away. Could we discuss this possibility? >>> "Matthew Gregg" <gr...@mu...> 09/29/03 09:02AM >>> http://pear.php.net=20 On Mon, 2003-09-29 at 10:18, Charlie Smith wrote: > Where is the API located for PEAR? >=20 > Could the work I'm doing on an OCI8 (Oracle) rewrite go to help in an = effort to port to PEAR compliant DB? >=20 > I've a question with regards to how the NOT NULL default '' fields would = be defined in the PEAR description? > I'd be inclined to define these types of fieds as NOT NULL in Oracle and = let the code or a trigger fill in the value > with something if needed. Any opinions? >=20 > I'm sorry, I'm not familiar with the PEAR API. Is this just a supporting= = library of php code? >=20 >=20 >=20 > >>> "Jeremy Buchmann" <je...@we...> 09/25/03 11:29AM >>> > Hi all, >=20 > I'm evaluating the use of phpESP for my company and have a few quick=20 > questions. >=20 > First, we use PostgreSQL for all our database needs. Since phpESP uses=20 > mySQL, we would either have to port it to PostgreSQL or assist in the=20 > port to PEAR. I'm experienced in PHP/PostgreSQL, and I think based on=20 > the number of lines in the code base that have 'mysql' in them, that I=20 > could do a port to PostgreSQL in 1-2 weeks. I'd rather not fork from=20 > the main distribution, so ideally I'd like to help in the port to PEAR,=20 > but I've never used PEAR. With a quick glance at the API, it looks=20 > easy enough...fairly similar to Perl's DBI. So my questions are, how=20 > is the PEAR port coming along? Would my help be welcome and useful? =20 > Would phpESP only use the database parts of PEAR? >=20 > Thanks, > Jeremy >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf=20 > _______________________________________________ > phpESP-devel mailing list > php...@li...=20 > https://lists.sourceforge.net/lists/listinfo/phpesp-devel=20 >=20 >=20 >=20 > = ---------------------------------------------------------------------------= --- > This message may contain confidential information, and is intended only = =66or the use of the individual(s) to whom it is addressed. >=20 >=20 > = =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D >=20 >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf=20 > _______________________________________________ > phpESP-devel mailing list > php...@li...=20 > https://lists.sourceforge.net/lists/listinfo/phpesp-devel=20 --=20 mcg ------------------------------------- The IT Lab (http://www.itlab.musc.edu) ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf=20 _______________________________________________ phpESP-devel mailing list php...@li...=20 https://lists.sourceforge.net/lists/listinfo/phpesp-devel=20 ---------------------------------------------------------------------------= --- This message may contain confidential information, and is intended only for= = the use of the individual(s) to whom it is addressed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D |
|
From: Christopher Z. <zo...@mu...> - 2003-09-30 14:35:10
|
You guys should work together and send the patches to the list. It would be best to patch against cvs. On Tue, Sep 30, 2003 at 08:27:44AM -0600, Charlie Smith wrote: > Looks like Jeremy Buchmann and I (Charlie Smith) could work on the PEAR port right away. Could we discuss this possibility? > > >>> "Matthew Gregg" <gr...@mu...> 09/29/03 09:02AM >>> > http://pear.php.net > On Mon, 2003-09-29 at 10:18, Charlie Smith wrote: > > Where is the API located for PEAR? > > > > Could the work I'm doing on an OCI8 (Oracle) rewrite go to help in an effort to port to PEAR compliant DB? > > > > I've a question with regards to how the NOT NULL default '' fields would be defined in the PEAR description? > > I'd be inclined to define these types of fieds as NOT NULL in Oracle and let the code or a trigger fill in the value > > with something if needed. Any opinions? > > > > I'm sorry, I'm not familiar with the PEAR API. Is this just a supporting library of php code? > > > > > > > > >>> "Jeremy Buchmann" <je...@we...> 09/25/03 11:29AM >>> > > Hi all, > > > > I'm evaluating the use of phpESP for my company and have a few quick > > questions. > > > > First, we use PostgreSQL for all our database needs. Since phpESP uses > > mySQL, we would either have to port it to PostgreSQL or assist in the > > port to PEAR. I'm experienced in PHP/PostgreSQL, and I think based on > > the number of lines in the code base that have 'mysql' in them, that I > > could do a port to PostgreSQL in 1-2 weeks. I'd rather not fork from > > the main distribution, so ideally I'd like to help in the port to PEAR, > > but I've never used PEAR. With a quick glance at the API, it looks > > easy enough...fairly similar to Perl's DBI. So my questions are, how > > is the PEAR port coming along? Would my help be welcome and useful? > > Would phpESP only use the database parts of PEAR? > > > > Thanks, > > Jeremy > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > phpESP-devel mailing list > > php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > > > > > > > > ------------------------------------------------------------------------------ > > This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. > > > > > > ============================================================================== > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > phpESP-devel mailing list > > php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > -- > mcg > ------------------------------------- > The IT Lab (http://www.itlab.musc.edu) > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > > > > ------------------------------------------------------------------------------ > This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. > > > ============================================================================== > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > |
|
From: Stefan C. <sch...@ea...> - 2003-10-01 05:51:20
|
Hmmm... I'm going to work on the port anytime soon, but it will be during next week. I think that if we are to work together, we have to share the work and follow a guideline. It seems to me that the closer we stay to the original code, the better. Indeed, it's less modofication and, also, since we know where each existing MySQL statement is, it's easier to share the work. For example, I can do "edit.inc". Or if we happen to work on the same file, we have a common ground that will help us to merge our changes more easilly. Stefan. > You guys should work together and send the patches to the list. > It would be best to patch against cvs. > > On Tue, Sep 30, 2003 at 08:27:44AM -0600, Charlie Smith wrote: > > Looks like Jeremy Buchmann and I (Charlie Smith) could work on the PEAR > > port right away. Could we discuss this possibility? > > > > >>> "Matthew Gregg" <gr...@mu...> 09/29/03 09:02AM >>> > > > > http://pear.php.net > > > > On Mon, 2003-09-29 at 10:18, Charlie Smith wrote: > > > Where is the API located for PEAR? > > > > > > Could the work I'm doing on an OCI8 (Oracle) rewrite go to help in an > > > effort to port to PEAR compliant DB? > > > > > > I've a question with regards to how the NOT NULL default '' fields > > > would be defined in the PEAR description? I'd be inclined to define > > > these types of fieds as NOT NULL in Oracle and let the code or a > > > trigger fill in the value with something if needed. Any opinions? > > > > > > I'm sorry, I'm not familiar with the PEAR API. Is this just a > > > supporting library of php code? > > > > > > >>> "Jeremy Buchmann" <je...@we...> 09/25/03 11:29AM >>> > > > > > > Hi all, > > > > > > I'm evaluating the use of phpESP for my company and have a few quick > > > questions. > > > > > > First, we use PostgreSQL for all our database needs. Since phpESP uses > > > mySQL, we would either have to port it to PostgreSQL or assist in the > > > port to PEAR. I'm experienced in PHP/PostgreSQL, and I think based on > > > the number of lines in the code base that have 'mysql' in them, that I > > > could do a port to PostgreSQL in 1-2 weeks. I'd rather not fork from > > > the main distribution, so ideally I'd like to help in the port to PEAR, > > > but I've never used PEAR. With a quick glance at the API, it looks > > > easy enough...fairly similar to Perl's DBI. So my questions are, how > > > is the PEAR port coming along? Would my help be welcome and useful? > > > Would phpESP only use the database parts of PEAR? > > > > > > Thanks, > > > Jeremy > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > phpESP-devel mailing list > > > php...@li... > > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > > > > > > > > > > > > ----------------------------------------------------------------------- > > >------- This message may contain confidential information, and is > > > intended only for the use of the individual(s) to whom it is addressed. > > > > > > > > > ======================================================================= > > >======= > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > phpESP-devel mailing list > > > php...@li... > > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > > > > -- > > mcg > > ------------------------------------- > > The IT Lab (http://www.itlab.musc.edu) > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > phpESP-devel mailing list > > php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > > > > > > > > ------------------------------------------------------------------------- > >----- This message may contain confidential information, and is intended > > only for the use of the individual(s) to whom it is addressed. > > > > > > ========================================================================= > >===== > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > phpESP-devel mailing list > > php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel |
|
From: Jeremy B. <je...@we...> - 2003-09-30 16:56:35
|
I can start fairly soon, assuming we decide to use phpESP. One thing I noticed right away was the database creation scripts. Are we going to write one for each database we want to support, or is there some way to generically specify a database design? One thing that caught my eye was the use of the ENUM type which is common in mySQL, but doesn't exist is PostgreSQL. However, it looks like all the ENUMs just hold two values, Y and N, which would map to the boolean type (true,false) in PostgreSQL. This will also affect the code, so I think it's something we should work out sooner rather than later. --Jeremy On Tuesday, September 30, 2003, at 07:27 AM, Charlie Smith wrote: > Looks like Jeremy Buchmann and I (Charlie Smith) could work on the > PEAR port right away. Could we discuss this possibility? > >>>> "Matthew Gregg" <gr...@mu...> 09/29/03 09:02AM >>> > http://pear.php.net > On Mon, 2003-09-29 at 10:18, Charlie Smith wrote: >> Where is the API located for PEAR? >> >> Could the work I'm doing on an OCI8 (Oracle) rewrite go to help in >> an effort to port to PEAR compliant DB? >> >> I've a question with regards to how the NOT NULL default '' fields >> would be defined in the PEAR description? >> I'd be inclined to define these types of fieds as NOT NULL in Oracle >> and let the code or a trigger fill in the value >> with something if needed. Any opinions? >> >> I'm sorry, I'm not familiar with the PEAR API. Is this just a >> supporting library of php code? >> >> >> >>>>> "Jeremy Buchmann" <je...@we...> 09/25/03 11:29AM >>> >> Hi all, >> >> I'm evaluating the use of phpESP for my company and have a few quick >> questions. >> >> First, we use PostgreSQL for all our database needs. Since phpESP >> uses >> mySQL, we would either have to port it to PostgreSQL or assist in the >> port to PEAR. I'm experienced in PHP/PostgreSQL, and I think based on >> the number of lines in the code base that have 'mysql' in them, that I >> could do a port to PostgreSQL in 1-2 weeks. I'd rather not fork from >> the main distribution, so ideally I'd like to help in the port to >> PEAR, >> but I've never used PEAR. With a quick glance at the API, it looks >> easy enough...fairly similar to Perl's DBI. So my questions are, how >> is the PEAR port coming along? Would my help be welcome and useful? >> Would phpESP only use the database parts of PEAR? >> >> Thanks, >> Jeremy >> |
|
From: Matthew G. <gr...@mu...> - 2003-09-30 17:19:59
|
Probably going to have to create/maintain DB creation scripts for each DB we plan on supporting. Changes made to ESP also should be done in a way that supports the all "supported" DB's. With mySQL as a given, I would target Postgres and Oracle as the supported databases. On Tue, Sep 30, 2003 at 09:56:26AM -0700, Jeremy Buchmann wrote: > I can start fairly soon, assuming we decide to use phpESP. One thing I > noticed right away was the database creation scripts. Are we going to > write one for each database we want to support, or is there some way to > generically specify a database design? One thing that caught my eye > was the use of the ENUM type which is common in mySQL, but doesn't > exist is PostgreSQL. However, it looks like all the ENUMs just hold > two values, Y and N, which would map to the boolean type (true,false) > in PostgreSQL. This will also affect the code, so I think it's > something we should work out sooner rather than later. > > > On Tuesday, September 30, 2003, at 07:27 AM, Charlie Smith wrote: > > >Looks like Jeremy Buchmann and I (Charlie Smith) could work on the > >PEAR port right away. Could we discuss this possibility? > > > >>>>"Matthew Gregg" <gr...@mu...> 09/29/03 09:02AM >>> > >http://pear.php.net > >On Mon, 2003-09-29 at 10:18, Charlie Smith wrote: > >>Where is the API located for PEAR? > >> > >>Could the work I'm doing on an OCI8 (Oracle) rewrite go to help in > >>an effort to port to PEAR compliant DB? > >> > >>I've a question with regards to how the NOT NULL default '' fields > >>would be defined in the PEAR description? > >>I'd be inclined to define these types of fieds as NOT NULL in Oracle > >>and let the code or a trigger fill in the value > >>with something if needed. Any opinions? > >> > >>I'm sorry, I'm not familiar with the PEAR API. Is this just a > >>supporting library of php code? > >> > >> > >> > >>>>>"Jeremy Buchmann" <je...@we...> 09/25/03 11:29AM >>> > >>Hi all, > >> > >>I'm evaluating the use of phpESP for my company and have a few quick > >>questions. > >> > >>First, we use PostgreSQL for all our database needs. Since phpESP > >>uses > >>mySQL, we would either have to port it to PostgreSQL or assist in the > >>port to PEAR. I'm experienced in PHP/PostgreSQL, and I think based on > >>the number of lines in the code base that have 'mysql' in them, that I > >>could do a port to PostgreSQL in 1-2 weeks. I'd rather not fork from > >>the main distribution, so ideally I'd like to help in the port to > >>PEAR, > >>but I've never used PEAR. With a quick glance at the API, it looks > >>easy enough...fairly similar to Perl's DBI. So my questions are, how > >>is the PEAR port coming along? Would my help be welcome and useful? > >>Would phpESP only use the database parts of PEAR? > >> > >>Thanks, > >>Jeremy > >> > > > > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > -- mcg ------------------------------------- The IT Lab (http://www.itlab.musc.edu) |
|
From: Charlie S. <Sm...@ld...> - 2003-10-01 17:35:34
|
I would also think we'd separate DB schema/scripts/logs for each database = type. The use of the ENUM type in mysql vs a check constraint in Oracle vs ? in = PostGreSQL. I would also advocate tying down the schema before proceeding with a rewrite of phpESP to accomodate PEAR DB. After the schema is tied down, we could = delve into=20 translating the mysql calls to the PEARDB calls, and proceed with unit = testing, if that sounds ok to=20 you guys. I've written a perl script that reads from a sqldump/export from phpMyAdmin and creates an Oracle schema for all the tables, triggers, indexes, = sequencers. So making modifications to what we want to do with the Oracle schema should be fairly easy to make for all the tables. I've also written a perl script to translate mysql function calls to = routines I've written, which in turn make calls to OCI8/Oracle. This scrip= t= can be modified to translate the mysql functions to the = PEARDB/MDB::functions(). We'll need to identify a PEARDB function for eac= h= of the mysql functions that we have in the code, and identify any = additional fields that would be needed. With that: =20 Let's discuss how to handle the schemas 1) ENUM type in PostGreSQL and Oracle. 2) the empty string in default values 3) default values vs NOT NULL >>> "Matthew Gregg" <gr...@mu...> 09/30/03 11:19AM >>> Probably going to have to create/maintain DB creation scripts for each DB we plan on supporting. Changes made to ESP also should be done in a way that supports the all "supported" DB's. With mySQL as a given, I would target Postgres and Oracle as the supported databases. On Tue, Sep 30, 2003 at 09:56:26AM -0700, Jeremy Buchmann wrote: > I can start fairly soon, assuming we decide to use phpESP. One thing I=20 > noticed right away was the database creation scripts. Are we going to=20 > write one for each database we want to support, or is there some way to=20 > generically specify a database design? One thing that caught my eye=20 > was the use of the ENUM type which is common in mySQL, but doesn't=20 > exist is PostgreSQL. However, it looks like all the ENUMs just hold=20 > two values, Y and N, which would map to the boolean type (true,false)=20 > in PostgreSQL. This will also affect the code, so I think it's=20 > something we should work out sooner rather than later. >=20 >=20 > On Tuesday, September 30, 2003, at 07:27 AM, Charlie Smith wrote: >=20 > >Looks like Jeremy Buchmann and I (Charlie Smith) could work on the=20 > >PEAR port right away. Could we discuss this possibility? > > > >>>>"Matthew Gregg" <gr...@mu...> 09/29/03 09:02AM >>> > >http://pear.php.net=20 > >On Mon, 2003-09-29 at 10:18, Charlie Smith wrote: > >>Where is the API located for PEAR? > >> > >>Could the work I'm doing on an OCI8 (Oracle) rewrite go to help in=20 > >>an effort to port to PEAR compliant DB? > >> > >>I've a question with regards to how the NOT NULL default '' fields=20 > >>would be defined in the PEAR description? > >>I'd be inclined to define these types of fieds as NOT NULL in Oracle=20 > >>and let the code or a trigger fill in the value > >>with something if needed. Any opinions? > >> > >>I'm sorry, I'm not familiar with the PEAR API. Is this just a=20 > >>supporting library of php code? > >> > >> > >> > >>>>>"Jeremy Buchmann" <je...@we...> 09/25/03 11:29AM >>> > >>Hi all, > >> > >>I'm evaluating the use of phpESP for my company and have a few quick > >>questions. > >> > >>First, we use PostgreSQL for all our database needs. Since phpESP=20 > >>uses > >>mySQL, we would either have to port it to PostgreSQL or assist in the > >>port to PEAR. I'm experienced in PHP/PostgreSQL, and I think based on > >>the number of lines in the code base that have 'mysql' in them, that I > >>could do a port to PostgreSQL in 1-2 weeks. I'd rather not fork from > >>the main distribution, so ideally I'd like to help in the port to=20 > >>PEAR, > >>but I've never used PEAR. With a quick glance at the API, it looks > >>easy enough...fairly similar to Perl's DBI. So my questions are, how > >>is the PEAR port coming along? Would my help be welcome and useful? > >>Would phpESP only use the database parts of PEAR? > >> > >>Thanks, > >>Jeremy > >> >=20 >=20 >=20 > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf=20 > _______________________________________________ > phpESP-devel mailing list > php...@li...=20 > https://lists.sourceforge.net/lists/listinfo/phpesp-devel=20 >=20 --=20 mcg ------------------------------------- The IT Lab (http://www.itlab.musc.edu) ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf=20 _______________________________________________ phpESP-devel mailing list php...@li...=20 https://lists.sourceforge.net/lists/listinfo/phpesp-devel=20 ---------------------------------------------------------------------------= --- This message may contain confidential information, and is intended only for= = the use of the individual(s) to whom it is addressed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D |
|
From: Stefan C. <sch...@ea...> - 2003-10-01 19:07:12
|
> I've also written a perl script to translate mysql function calls to > routines I've written, which in turn make calls to OCI8/Oracle. This I'd be happy to see that ! > > > With that: > Let's discuss how to handle the schemas > 1) ENUM type in PostGreSQL and Oracle. > 2) the empty string in default values > 3) default values vs NOT NULL My Oracle and PostgreSQL is limited, so I ask the question : are we planning to make severeal schema with the hope to have minimum code rewrite on the phpESP side ? (I guess it makes sense). Stefan > > >>> "Matthew Gregg" <gr...@mu...> 09/30/03 11:19AM >>> > > Probably going to have to create/maintain DB creation scripts for each > DB we plan on supporting. Changes made to ESP also should be done in > a way that supports the all "supported" DB's. With mySQL as a given, I > would target Postgres and Oracle as the supported databases. > > On Tue, Sep 30, 2003 at 09:56:26AM -0700, Jeremy Buchmann wrote: > > I can start fairly soon, assuming we decide to use phpESP. One thing I > > noticed right away was the database creation scripts. Are we going to > > write one for each database we want to support, or is there some way to > > generically specify a database design? One thing that caught my eye > > was the use of the ENUM type which is common in mySQL, but doesn't > > exist is PostgreSQL. However, it looks like all the ENUMs just hold > > two values, Y and N, which would map to the boolean type (true,false) > > in PostgreSQL. This will also affect the code, so I think it's > > something we should work out sooner rather than later. > > > > On Tuesday, September 30, 2003, at 07:27 AM, Charlie Smith wrote: > > >Looks like Jeremy Buchmann and I (Charlie Smith) could work on the > > >PEAR port right away. Could we discuss this possibility? > > > > > >>>>"Matthew Gregg" <gr...@mu...> 09/29/03 09:02AM >>> > > > > > >http://pear.php.net > > > > > >On Mon, 2003-09-29 at 10:18, Charlie Smith wrote: > > >>Where is the API located for PEAR? > > >> > > >>Could the work I'm doing on an OCI8 (Oracle) rewrite go to help in > > >>an effort to port to PEAR compliant DB? > > >> > > >>I've a question with regards to how the NOT NULL default '' fields > > >>would be defined in the PEAR description? > > >>I'd be inclined to define these types of fieds as NOT NULL in Oracle > > >>and let the code or a trigger fill in the value > > >>with something if needed. Any opinions? > > >> > > >>I'm sorry, I'm not familiar with the PEAR API. Is this just a > > >>supporting library of php code? > > >> > > >>>>>"Jeremy Buchmann" <je...@we...> 09/25/03 11:29AM >>> > > >> > > >>Hi all, > > >> > > >>I'm evaluating the use of phpESP for my company and have a few quick > > >>questions. > > >> > > >>First, we use PostgreSQL for all our database needs. Since phpESP > > >>uses > > >>mySQL, we would either have to port it to PostgreSQL or assist in the > > >>port to PEAR. I'm experienced in PHP/PostgreSQL, and I think based on > > >>the number of lines in the code base that have 'mysql' in them, that I > > >>could do a port to PostgreSQL in 1-2 weeks. I'd rather not fork from > > >>the main distribution, so ideally I'd like to help in the port to > > >>PEAR, > > >>but I've never used PEAR. With a quick glance at the API, it looks > > >>easy enough...fairly similar to Perl's DBI. So my questions are, how > > >>is the PEAR port coming along? Would my help be welcome and useful? > > >>Would phpESP only use the database parts of PEAR? > > >> > > >>Thanks, > > >>Jeremy > > > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > phpESP-devel mailing list > > php...@li... > > https://lists.sourceforge.net/lists/listinfo/phpesp-devel |
|
From: Jeremy B. <je...@we...> - 2003-10-01 20:17:31
|
On Wednesday, October 1, 2003, at 02:13 PM, Stefan Champailler wrote:
>> With that:
>> Let's discuss how to handle the schemas
>> 1) ENUM type in PostGreSQL and Oracle.
>> 2) the empty string in default values
>> 3) default values vs NOT NULL
>
> My Oracle and PostgreSQL is limited, so I ask the question : are we
> planning
> to make severeal schema with the hope to have minimum code rewrite on
> the
> phpESP side ? (I guess it makes sense).
>
I think it's best to work out a schema that:
1. Is as generic as possible so we can avoid or minimize code like
this:
if ($DB == "mysql") {
do something...
}
elseif ($DB == "postgresql") {
do something else...
}
elseif ($DB == "oracle") {
etc, etc
}
2. Is still functionally the same as the current one (I don't think
anyone wants to get into a database redesign). Let me clarify
that...it's not just functionally the same, it is the same except we
may change some data types to something more generic and rename some
fields to avoid keyword collisions.
So it would be the same generic schema for each database, but different
creation scripts and things like that. At least, that's how I envision
it.
--Jeremy
|
|
From: James E. F. <jf...@uv...> - 2003-10-02 00:43:49
|
Jeremy Buchmann wrote:
> On Wednesday, October 1, 2003, at 02:13 PM, Stefan Champailler wrote:
>
>>> With that:
>>> Let's discuss how to handle the schemas
>>> 1) ENUM type in PostGreSQL and Oracle.
>>> 2) the empty string in default values
>>> 3) default values vs NOT NULL
>>
>>
>> My Oracle and PostgreSQL is limited, so I ask the question : are we
>> planning
>> to make severeal schema with the hope to have minimum code rewrite on the
>> phpESP side ? (I guess it makes sense).
>>
>
> I think it's best to work out a schema that:
>
> 1. Is as generic as possible so we can avoid or minimize code like this:
>
> if ($DB == "mysql") {
> do something...
> }
> elseif ($DB == "postgresql") {
> do something else...
> }
> elseif ($DB == "oracle") {
> etc, etc
> }
>
> 2. Is still functionally the same as the current one (I don't think
> anyone wants to get into a database redesign). Let me clarify
> that...it's not just functionally the same, it is the same except we may
> change some data types to something more generic and rename some fields
> to avoid keyword collisions.
>
> So it would be the same generic schema for each database, but different
> creation scripts and things like that. At least, that's how I envision it.
Please, please avoid huge if/else blocks if possible. (Even if I did
not in the past.) I think that PEAR::DB will help avoid this in most
cases. By making phpESP database engine independant, use of neat DB
features will likely have to be sacrificed. When it comes down to it,
if a suitible ``enum'' type does not exist accross the board (in a way
that will be acessible with the same SQL query), then just use a numeric
type, and map it to an enumeration only inside the PHP code. If NULL is
not available as a default, don't use it, use -1 and remap all internal
representation that needs it. I really hope that NULL will be an
option, because it is the best way to represent the lack of a value.
NULL is especially important in the response data to indicate that the
question was left blank. Perhaps, we will have to avoid counting on
defaults all together, and explicitly set all fields from the code.
If all else fails, and there is someplace where it looks like an if/else
is needed, then try to avoid it with OO/polymorphism. This may be a
better general approach anyway, with objects representing the database
tables.
I have consitently found that some of the phpesp data is poorly suited
for storage in a relational db. This is compounded by the fact that
mysql (which was the initial customer reqirement) was much happier with
a few tables with lots of records than lots of tables with few records.
I believe XML w/ a well desinged schema/dtd (using some unknown sort
of storage) would be far better for the representation of the survey
data (and could provide multi-lingual support much more redily than the
current organization). User/group tables are probably best done with
some traditional db or directory (SQL or LDAP).
-James
|
|
From: James E. F. <jf...@uv...> - 2003-10-02 02:00:25
|
James E. Flemer wrote:
> Jeremy Buchmann wrote:
>
>> On Wednesday, October 1, 2003, at 02:13 PM, Stefan Champailler wrote:
>>
>>>> With that:
>>>> Let's discuss how to handle the schemas
>>>> 1) ENUM type in PostGreSQL and Oracle.
>>>> 2) the empty string in default values
>>>> 3) default values vs NOT NULL
>>>
>>>
>>>
>>> My Oracle and PostgreSQL is limited, so I ask the question : are we
>>> planning
>>> to make severeal schema with the hope to have minimum code rewrite on
>>> the
>>> phpESP side ? (I guess it makes sense).
>>>
>>
>> I think it's best to work out a schema that:
>>
>> 1. Is as generic as possible so we can avoid or minimize code like
>> this:
>>
>> if ($DB == "mysql") {
>> do something...
>> }
>> elseif ($DB == "postgresql") {
>> do something else...
>> }
>> elseif ($DB == "oracle") {
>> etc, etc
>> }
>>
>> 2. Is still functionally the same as the current one (I don't think
>> anyone wants to get into a database redesign). Let me clarify
>> that...it's not just functionally the same, it is the same except we
>> may change some data types to something more generic and rename some
>> fields to avoid keyword collisions.
>>
>> So it would be the same generic schema for each database, but
>> different creation scripts and things like that. At least, that's how
>> I envision it.
>
>
> Please, please avoid huge if/else blocks if possible. (Even if I did
> not in the past.) I think that PEAR::DB will help avoid this in most
> cases. By making phpESP database engine independant, use of neat DB
> features will likely have to be sacrificed. When it comes down to it,
> if a suitible ``enum'' type does not exist accross the board (in a way
> that will be acessible with the same SQL query), then just use a numeric
> type, and map it to an enumeration only inside the PHP code. If NULL is
> not available as a default, don't use it, use -1 and remap all internal
> representation that needs it. I really hope that NULL will be an
> option, because it is the best way to represent the lack of a value.
> NULL is especially important in the response data to indicate that the
> question was left blank. Perhaps, we will have to avoid counting on
> defaults all together, and explicitly set all fields from the code.
>
> If all else fails, and there is someplace where it looks like an if/else
> is needed, then try to avoid it with OO/polymorphism. This may be a
> better general approach anyway, with objects representing the database
> tables.
>
> I have consitently found that some of the phpesp data is poorly suited
> for storage in a relational db. This is compounded by the fact that
> mysql (which was the initial customer reqirement) was much happier with
> a few tables with lots of records than lots of tables with few records.
> I believe XML w/ a well desinged schema/dtd (using some unknown sort of
> storage) would be far better for the representation of the survey data
> (and could provide multi-lingual support much more redily than the
> current organization). User/group tables are probably best done with
> some traditional db or directory (SQL or LDAP).
Some people find it strange to talk to yourself...
Some (ancient) XML stuff I played around with for phpESP is on the
website here[1]. I think the stuff there was proof of concept of using
xml storage with xsl transforms for html layout. There is probably some
java code that I used to execute the xsl somewhere on my computer if
anyone is interested ...
[1] http://phpesp.org/xml/
-James
|
|
From: Stefan C. <sch...@ea...> - 2003-10-03 18:06:54
|
Sorry to bring this back on the table, but I don't rememebr why we ended up deciding for PEAR support. Why not use ODBC instead ? After all, it's a DB abstraction too... I ask because I feel I'll need transaction support and that is not clearly documented in PEAR (but is in ODBC). Just to make for fun, today I'm adding a feature to be able to include a picture with a question. stF |
|
From: James E. F. <jf...@uv...> - 2003-10-04 00:46:49
|
Stefan Champailler wrote: > Sorry to bring this back on the table, but I don't rememebr why we ended up > deciding for PEAR support. Why not use ODBC instead ? After all, it's a DB > abstraction too... > > I ask because I feel I'll need transaction support and that is not clearly > documented in PEAR (but is in ODBC). > > Just to make for fun, today I'm adding a feature to be able to include a > picture with a question. Well, I would prefer PEAR to ODBC, but do what you have to do Stefan. Transactions are one of those features that will probably make phpESP less portable (with respect to database engines). PEAR for the moment is the de-facto database abstraction layer for PHP, quite like DBI is to Perl. That in itself is a very compelling reason to use it. Using ODBC, I feel you will have to write more code than using DB. I am not sure which would be better for portability. As for including pictures, I assume you are using the http file upload capability? You can of course embed an image (or any other media) at just about any point in a survey already, since you can add arbitrary HTML to most survey fields during design. I believe with the section text question type, this has become even more flexible, as you can now even place HTML between questions. Take it easy, -James |
|
From: Stefan C. <sch...@ea...> - 2003-10-06 15:15:57
|
I've just came to several conclusions : - my developments will be done before yours here, I'm so short on time. By the time will have backported them into the original phpESP, yours will be done. So I'm sad to realize that I'll have to implement things that probably won't get into the main branch :( But anyway, I'll show you, just in case. - PEAR versus ODBC : I'll probably go with ODBC because of transactions (unless one tells me how to achieve transactions with PEAR). Since it will be ODBC on Oracle, I'll be happy to contribute to debugging SQL scripts. - For advanced reporting, I probably won't go as far as others, but agin, I can show you what I've done. - For the rest, much of my work is to make Bridgestone "dumb" enough for non-IT people. For example, I remove some funtionalities that looks "complicated" or add others that sounds easier. - I'm still writing the user manual and since it's pretty generic, I think a big part of it will be reusable, as long as we re-do the screen shots. Stefan |
|
From: Stefan C. <sch...@ea...> - 2003-10-09 11:04:34
|
As a general warning, be very carefull with the user privileges and designer management, there are a lot of small glitches... Especially, when you give a designer the right to create/edit other designers. I've just spent 3 hours fixing that and I'm still not done... stF |
|
From: Stefan C. <sch...@ea...> - 2003-10-09 11:25:54
|
In the acl, is this right : pall - all the groups for which the current user can create respondent accounts AND designers accounts puser - all the groups for which the current user can create respondent accounts only Stefan ? |
|
From: Stefan C. <sch...@ea...> - 2003-10-01 19:16:38
|
I've added a functionality to put all the results for a multiple-choice question on a graphical result. It also gives another point of view on the answer to those questions. I'd be happy to post a screenshot here, but I really don't know if it's possible/if you would tolerate that. Just tell me... I can also email directly to you. stF |
|
From: Matthew G. <gr...@mu...> - 2003-10-01 19:19:56
|
Can you guys post diffs against CVS of the work you're doing, so that we can see it? On Wed, Oct 01, 2003 at 09:22:08PM +0000, Stefan Champailler wrote: > I've added a functionality to put all the results for a multiple-choice > question on a graphical result. It also gives another point of view on the > answer to those questions. > > I'd be happy to post a screenshot here, but I really don't know if it's > possible/if you would tolerate that. Just tell me... I can also email > directly to you. > > stF > > > > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > -- mcg ------------------------------------- The IT Lab (http://www.itlab.musc.edu) |
|
From: James E. F. <jf...@uv...> - 2003-10-02 00:13:00
|
Stefan Champailler wrote: > I've added a functionality to put all the results for a multiple-choice > question on a graphical result. It also gives another point of view on the > answer to those questions. > > I'd be happy to post a screenshot here, but I really don't know if it's > possible/if you would tolerate that. Just tell me... I can also email > directly to you. > > stF You can send a screenshot to me directly and I will put it somewhere in the contrib/ part of the phpesp web site. Same with patches (for immidiate use/testing until they get merged into the tree). I think all developers (listed on the sf.net project page) should have write access to the webspace (and are welcome to (ab)use the privilege). -James |
|
From: Stefan C. <sch...@ea...> - 2003-10-03 18:06:53
|
In funcs.inc (esp 1.6.1) : there is
$where = strtolower(ereg_replace(' +','_',$where));
if(!ereg('^[A-Za-z0-9_]+$',$where)) // Valid chars are [A-Za-z0-9_]
where you check for uppercase right after having "lower cased" ...
Is there an explanation for that ?
stF
|
|
From: Stefan C. <sch...@ea...> - 2003-10-03 18:06:53
|
This variable is set both in $GLOBALS and as global. I think this is to ensure some compatibility across verions of PHP, but I'm not sure. BTW, what is the target ? Right now, I use PHP 4.3 ($_REQUEST, etc.) stF |
|
From: Charlie S. <Sm...@ld...> - 2003-10-02 19:52:31
|
Yes, the use of PEARDB should make the long if's largely unnecessary.
=46or field definitions, I'd be inclined to go with NULLs as well. We'd us=
e=
the NULL and NOT NULL qualifier in the field definitions and work out the =
default values in the code. So we'd keep fields defined as NOT NULL in =
Oracle. The field definition of fieldname ... NOT NULL default '' is not=
=
valid in Oracle. Also, in Oracle, NULL fields are detected differently =
that fields with data in them when using a select statement. ie. select * =
=66rom table where field IS null=20
would be the code for going against the Oracle table rather than select *=
=
=66rom table where field =3D null (This is an invalid select as you have=
=
to use 'is' and 'is not' null when detecting null fields in the oracle =
tables, not =3D and !=3D. So if there is code in phpESP which references =
empty string in select statements, it would need to be modified.
I had thought we may want to replace the NOT NULL default '' with just =
default ' '. But had my reservations. Thanks for your input on this, =
though I confess I am still a bit confused. In Oracle if there is no =
supplied value for a nullable field (any field not declared as NOT NULL), =
it's value is NULL by default. If you had a choice between default NULL an=
d=
NOT NULL, which would you want to go with? =20
=46or following fields we could translate to Oracle as follows?
MySQL becomes Oracle
int(10) unsigned NOT NULL default '0' NOT NULL
default NULL, NULL
int(10) unsigned default '0' default 0
enum('Y','N') NOT NULL default 'N' NOT NULL (with check constraint=
=
*)
NOT NULL default '' NOT NULL
* check constraint syntax:
alter table designer
add constraint designer_pdesign_ck
check (pdesign in ('Y','N'));
We could also put a trigger on the table/field so that on insert or update,=
=
if the new field value were null, it would get populated with 'N'. We =
could handle all the other default values this way except for the empty =
string ''. We'd have to modify the code for this where it selects from =
table where field =3D ''.
=46or ENUM types, a check constraint can be used in Oracle, to make sure =
values are matched against those we want to allow.
What would the syntax look like in PostGres?
Does this sound agreeable?
>>> "James E. Flemer" <jf...@uv...> 10/01/03 06:43PM >>>
Jeremy Buchmann wrote:
> On Wednesday, October 1, 2003, at 02:13 PM, Stefan Champailler wrote:
>=20
>>> With that:
>>> Let's discuss how to handle the schemas
>>> 1) ENUM type in PostGreSQL and Oracle.
>>> 2) the empty string in default values
>>> 3) default values vs NOT NULL
>>
>>
>> My Oracle and PostgreSQL is limited, so I ask the question : are we=20
>> planning
>> to make severeal schema with the hope to have minimum code rewrite on the
>> phpESP side ? (I guess it makes sense).
>>
>=20
> I think it's best to work out a schema that:
>=20
> 1. Is as generic as possible so we can avoid or minimize code like this:
>=20
> if ($DB =3D=3D "mysql") {
> do something...
> }
> elseif ($DB =3D=3D "postgresql") {
> do something else...
> }
> elseif ($DB =3D=3D "oracle") {
> etc, etc
> }
>=20
> 2. Is still functionally the same as the current one (I don't think=20
> anyone wants to get into a database redesign). Let me clarify=20
> that...it's not just functionally the same, it is the same except we may=
=20
> change some data types to something more generic and rename some fields=20
> to avoid keyword collisions.
>=20
> So it would be the same generic schema for each database, but different=20
> creation scripts and things like that. At least, that's how I envision =
it.
Please, please avoid huge if/else blocks if possible. (Even if I did=20
not in the past.) I think that PEAR::DB will help avoid this in most=20
cases. By making phpESP database engine independant, use of neat DB=20
=66eatures will likely have to be sacrificed. When it comes down to it,=20
if a suitible ``enum'' type does not exist accross the board (in a way=20
that will be acessible with the same SQL query), then just use a numeric=20
type, and map it to an enumeration only inside the PHP code. If NULL is=20
not available as a default, don't use it, use -1 and remap all internal=20
representation that needs it. I really hope that NULL will be an=20
option, because it is the best way to represent the lack of a value.=20
NULL is especially important in the response data to indicate that the=20
question was left blank. Perhaps, we will have to avoid counting on=20
defaults all together, and explicitly set all fields from the code.
If all else fails, and there is someplace where it looks like an if/else=20
is needed, then try to avoid it with OO/polymorphism. This may be a=20
better general approach anyway, with objects representing the database=20
tables.
I have consitently found that some of the phpesp data is poorly suited=20
=66or storage in a relational db. This is compounded by the fact that=20
mysql (which was the initial customer reqirement) was much happier with=20
a few tables with lots of records than lots of tables with few records.=20
I believe XML w/ a well desinged schema/dtd (using some unknown sort=20
of storage) would be far better for the representation of the survey=20
data (and could provide multi-lingual support much more redily than the=20
current organization). User/group tables are probably best done with=20
some traditional db or directory (SQL or LDAP).
-James
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf=20
_______________________________________________
phpESP-devel mailing list
php...@li...=20
https://lists.sourceforge.net/lists/listinfo/phpesp-devel=20
---------------------------------------------------------------------------=
---
This message may contain confidential information, and is intended only for=
=
the use of the individual(s) to whom it is addressed.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D
|
|
From: Charlie S. <Sm...@ld...> - 2003-10-06 13:29:11
|
So code would be modified to be: if (mystring=3D=3D'') mysql=3D'select * from designer where username is null'; else mysql=3D'select * from designer where username =3D ' + = quotefunc(mystring); See = http://www.tek-tips.com/viewthread.cfm?spid=3D759&newpid=3D759&sqid=3D65748= 0= for further discussion on topic of empty string. >>> "Charlie Smith" <Sm...@ld...> 10/02/03 01:51PM >>> Yes, the use of PEARDB should make the long if's largely unnecessary. =46or field definitions, I'd be inclined to go with NULLs as well. We'd us= e= the NULL and NOT NULL qualifier in the field definitions and work out the = default values in the code. So we'd keep fields defined as NOT NULL in = Oracle. The field definition of fieldname ... NOT NULL default '' is not= = valid in Oracle. Also, in Oracle, NULL fields are detected differently = that fields with data in them when using a select statement. ie. select * = =66rom table where field IS null=20 would be the code for going against the Oracle table rather than select *= = =66rom table where field =3D null (This is an invalid select as you have= = to use 'is' and 'is not' null when detecting null fields in the oracle = tables, not =3D and !=3D. So if there is code in phpESP which references = empty string in select statements, it would need to be modified. I had thought we may want to replace the NOT NULL default '' with just = default ' '. But had my reservations. Thanks for your input on this, = though I confess I am still a bit confused. In Oracle if there is no = supplied value for a nullable field (any field not declared as NOT NULL), = it's value is NULL by default. If you had a choice between default NULL an= d= NOT NULL, which would you want to go with? =20 =46or following fields we could translate to Oracle as follows? MySQL becomes Oracle int(10) unsigned NOT NULL default '0' NOT NULL default NULL, NULL int(10) unsigned default '0' default 0 enum('Y','N') NOT NULL default 'N' NOT NULL (with check constraint= = *) NOT NULL default '' NOT NULL * check constraint syntax: alter table designer add constraint designer_pdesign_ck check (pdesign in ('Y','N')); We could also put a trigger on the table/field so that on insert or update,= = if the new field value were null, it would get populated with 'N'. We = could handle all the other default values this way except for the empty = string ''. We'd have to modify the code for this where it selects from = table where field =3D ''. =46or ENUM types, a check constraint can be used in Oracle, to make sure = values are matched against those we want to allow. What would the syntax look like in PostGres? Does this sound agreeable? >>> "James E. Flemer" <jf...@uv...> 10/01/03 06:43PM >>> Jeremy Buchmann wrote: > On Wednesday, October 1, 2003, at 02:13 PM, Stefan Champailler wrote: >=20 >>> With that: >>> Let's discuss how to handle the schemas >>> 1) ENUM type in PostGreSQL and Oracle. >>> 2) the empty string in default values >>> 3) default values vs NOT NULL >> >> >> My Oracle and PostgreSQL is limited, so I ask the question : are we=20 >> planning >> to make severeal schema with the hope to have minimum code rewrite on the >> phpESP side ? (I guess it makes sense). >> >=20 > I think it's best to work out a schema that: >=20 > 1. Is as generic as possible so we can avoid or minimize code like this: >=20 > if ($DB =3D=3D "mysql") { > do something... > } > elseif ($DB =3D=3D "postgresql") { > do something else... > } > elseif ($DB =3D=3D "oracle") { > etc, etc > } >=20 > 2. Is still functionally the same as the current one (I don't think=20 > anyone wants to get into a database redesign). Let me clarify=20 > that...it's not just functionally the same, it is the same except we may= =20 > change some data types to something more generic and rename some fields=20 > to avoid keyword collisions. >=20 > So it would be the same generic schema for each database, but different=20 > creation scripts and things like that. At least, that's how I envision = it. Please, please avoid huge if/else blocks if possible. (Even if I did=20 not in the past.) I think that PEAR::DB will help avoid this in most=20 cases. By making phpESP database engine independant, use of neat DB=20 =66eatures will likely have to be sacrificed. When it comes down to it,=20 if a suitible ``enum'' type does not exist accross the board (in a way=20 that will be acessible with the same SQL query), then just use a numeric=20 type, and map it to an enumeration only inside the PHP code. If NULL is=20 not available as a default, don't use it, use -1 and remap all internal=20 representation that needs it. I really hope that NULL will be an=20 option, because it is the best way to represent the lack of a value.=20 NULL is especially important in the response data to indicate that the=20 question was left blank. Perhaps, we will have to avoid counting on=20 defaults all together, and explicitly set all fields from the code. If all else fails, and there is someplace where it looks like an if/else=20 is needed, then try to avoid it with OO/polymorphism. This may be a=20 better general approach anyway, with objects representing the database=20 tables. I have consitently found that some of the phpesp data is poorly suited=20 =66or storage in a relational db. This is compounded by the fact that=20 mysql (which was the initial customer reqirement) was much happier with=20 a few tables with lots of records than lots of tables with few records.=20 I believe XML w/ a well desinged schema/dtd (using some unknown sort=20 of storage) would be far better for the representation of the survey=20 data (and could provide multi-lingual support much more redily than the=20 current organization). User/group tables are probably best done with=20 some traditional db or directory (SQL or LDAP). -James ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf=20 _______________________________________________ phpESP-devel mailing list php...@li...=20 https://lists.sourceforge.net/lists/listinfo/phpesp-devel=20 ---------------------------------------------------------------------------= --- This message may contain confidential information, and is intended only for= = the use of the individual(s) to whom it is addressed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf=20 _______________________________________________ phpESP-devel mailing list php...@li...=20 https://lists.sourceforge.net/lists/listinfo/phpesp-devel=20 ---------------------------------------------------------------------------= --- This message may contain confidential information, and is intended only for= = the use of the individual(s) to whom it is addressed. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D |
|
From: Matthew G. <gr...@mu...> - 2003-09-29 15:49:37
|
http://pear.php.net On Mon, 2003-09-29 at 10:18, Charlie Smith wrote: > Where is the API located for PEAR? > > Could the work I'm doing on an OCI8 (Oracle) rewrite go to help in an effort to port to PEAR compliant DB? > > I've a question with regards to how the NOT NULL default '' fields would be defined in the PEAR description? > I'd be inclined to define these types of fieds as NOT NULL in Oracle and let the code or a trigger fill in the value > with something if needed. Any opinions? > > I'm sorry, I'm not familiar with the PEAR API. Is this just a supporting library of php code? > > > > >>> "Jeremy Buchmann" <je...@we...> 09/25/03 11:29AM >>> > Hi all, > > I'm evaluating the use of phpESP for my company and have a few quick > questions. > > First, we use PostgreSQL for all our database needs. Since phpESP uses > mySQL, we would either have to port it to PostgreSQL or assist in the > port to PEAR. I'm experienced in PHP/PostgreSQL, and I think based on > the number of lines in the code base that have 'mysql' in them, that I > could do a port to PostgreSQL in 1-2 weeks. I'd rather not fork from > the main distribution, so ideally I'd like to help in the port to PEAR, > but I've never used PEAR. With a quick glance at the API, it looks > easy enough...fairly similar to Perl's DBI. So my questions are, how > is the PEAR port coming along? Would my help be welcome and useful? > Would phpESP only use the database parts of PEAR? > > Thanks, > Jeremy > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel > > > > ------------------------------------------------------------------------------ > This message may contain confidential information, and is intended only for the use of the individual(s) to whom it is addressed. > > > ============================================================================== > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > phpESP-devel mailing list > php...@li... > https://lists.sourceforge.net/lists/listinfo/phpesp-devel -- mcg ------------------------------------- The IT Lab (http://www.itlab.musc.edu) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X