|
From: Patrick M. <mai...@st...> - 2001-08-28 16:02:56
|
Hello, I'm a bit confused. I just got the actual version from cvs. The php-scripts use a new db structure but the file createdb.sql (and my database of course) contains still the old one. greetz, patrick! |
|
From: Ben C. <php...@be...> - 2001-08-28 17:14:54
|
Yup, createdb.sql hasn't been updated for the new db structure yet. But you can use dbchanges.sql and perms.sql to move to the new table structure. createdb.sql will be updated before the release is made -- I haven't done it yet because the database changes aren't final yet. :) On Tue, Aug 28, 2001 at 06:02:48PM +0200, Patrick Mairif wrote: > Hello, > > I'm a bit confused. I just got the actual version from cvs. > The php-scripts use a new db structure but the file createdb.sql (and my > database of course) contains still the old one. > > greetz, patrick! > > > _______________________________________________ > phpbt-dev mailing list > php...@li... > http://lists.sourceforge.net/lists/listinfo/phpbt-dev |
|
From: Patrick M. <mai...@st...> - 2001-08-28 17:55:15
|
On Tue, 28 Aug 2001, Ben Curtis wrote: > Yup, createdb.sql hasn't been updated for the new db structure yet. > But you can use dbchanges.sql and perms.sql to move to the new table > structure. createdb.sql will be updated before the release is made -- I > haven't done it yet because the database changes aren't final yet. :) perhaps there is space for additional suggestions, if the changes aren't complete: My ISP let me use only one mysql database, so phpBT hast to share the same db with my other projects. I'm sure more people are in this situation, so tablenames starting with a prefix like 'BT_' or 'phpBT_' would be great. Is this possible? I could do the changes. greetz! |
|
From: Ben C. <php...@be...> - 2001-08-28 18:05:07
|
I was thinking of this the other night. What should happen is that a constant is added to config.php for the table name prefix, like phpbt_. Then constants need to be added for each table name using the prefix constant. Then all the queries need to be changed to use the new constants -- instead of "select from auth_user ..." it would be "select from ".USER_TABLE." ... If you'd like to do this I can add you to the project as a developer. It doesn't have to be right away, but it would also be nice to have this prefix configurable via the configure script and have that script change the db schema file accordingly. On Tue, Aug 28, 2001 at 07:55:08PM +0200, Patrick Mairif wrote: > On Tue, 28 Aug 2001, Ben Curtis wrote: > > > Yup, createdb.sql hasn't been updated for the new db structure yet. > > But you can use dbchanges.sql and perms.sql to move to the new table > > structure. createdb.sql will be updated before the release is made -- I > > haven't done it yet because the database changes aren't final yet. :) > > perhaps there is space for additional suggestions, if the changes aren't > complete: > > My ISP let me use only one mysql database, so phpBT hast to share the > same db with my other projects. I'm sure more people are in this > situation, so tablenames starting with a prefix like 'BT_' or 'phpBT_' > would be great. > Is this possible? I could do the changes. > > greetz! > > > _______________________________________________ > phpbt-dev mailing list > php...@li... > http://lists.sourceforge.net/lists/listinfo/phpbt-dev |
|
From: Patrick M. <mai...@st...> - 2001-08-28 20:36:02
|
On Tue, 28 Aug 2001, Ben Curtis wrote: > What should happen is that a constant is added to config.php for the > table name prefix, like phpbt_. Then constants need to be added for > each table name using the prefix constant. Then all the queries need to > be changed to use the new constants -- instead of "select from auth_user > ..." it would be "select from ".USER_TABLE." ... Why not one constant for the prefix that is used in all queries? The other suggestion from Javier sounds good, too, but I think it is not necessary. I think an array is a bit overloaded, isn't it? > If you'd like to do this I can add you to the project as a developer. ok, I would do this, just add me! > It doesn't have to be right away, but it would also be nice to have this > prefix configurable via the configure script and have that script change > the db schema file accordingly. gonna see, what I can do. :) |
|
From: Ben C. <php...@be...> - 2001-08-28 20:45:48
|
On Tue, Aug 28, 2001 at 10:35:56PM +0200, Patrick Mairif wrote: > On Tue, 28 Aug 2001, Ben Curtis wrote: > > What should happen is that a constant is added to config.php for the > > table name prefix, like phpbt_. Then constants need to be added for > > each table name using the prefix constant. Then all the queries need to > > be changed to use the new constants -- instead of "select from auth_user > > ..." it would be "select from ".USER_TABLE." ... > > Why not one constant for the prefix that is used in all queries? That's an alternative... let me let it roll around in my head a bit > > The other suggestion from Javier sounds good, too, but I think it is not > necessary. I think an array is a bit overloaded, isn't it? Hmm, I didn't see a suggestion from Javier -- either I missed it or he didn't send it to the list. :) > > > If you'd like to do this I can add you to the project as a developer. > > ok, I would do this, just add me! You've been added > > > It doesn't have to be right away, but it would also be nice to have this > > prefix configurable via the configure script and have that script change > > the db schema file accordingly. > > gonna see, what I can do. :) > Cool! And, welcome aboard! |
|
From: Patrick M. <mai...@st...> - 2001-08-28 20:57:06
|
On Tue, 28 Aug 2001, Ben Curtis wrote: > Hmm, I didn't see a suggestion from Javier -- either I missed it or he didn't send it to the list. :) I sent you a copy. > Cool! And, welcome aboard! thank you! :) |
|
From: Javier S. <js...@si...> - 2001-08-28 23:22:59
|
Well the idea is to have different table names in 1 array .... this array is a global var .... it is a bit more complicated that just add a prefix ... But in fact it can be very usefull for some special application ... For example, when i use phpbt auth's phpbt tables for other personal application in the same site. So it would be more logical to have one unique table named user_auth ... You see what i mean ? :-) Patrick Mairif wrote: >On Tue, 28 Aug 2001, Ben Curtis wrote: > >>Hmm, I didn't see a suggestion from Javier -- either I missed it or he didn't send it to the list. :) >> > >I sent you a copy. > >>Cool! And, welcome aboard! >> > >thank you! :) > > >_______________________________________________ >phpbt-dev mailing list >php...@li... >http://lists.sourceforge.net/lists/listinfo/phpbt-dev > |
|
From: Ben C. <php...@be...> - 2001-08-29 17:13:25
|
As promised, I've rolled it around in my head a bit, and I think I would like to have a constant for the prefix and a constant for each table name. This would allow for a prefix or not, and would allow people who prefer StudlyCaps table names to have them. And since we would be editing every query for the prefix constant anyway, we might as well use table name constants. Thoughts? On Tue, Aug 28, 2001 at 01:45:40PM -0700, Ben Curtis wrote: > On Tue, Aug 28, 2001 at 10:35:56PM +0200, Patrick Mairif wrote: > > On Tue, 28 Aug 2001, Ben Curtis wrote: > > > What should happen is that a constant is added to config.php for the > > > table name prefix, like phpbt_. Then constants need to be added for > > > each table name using the prefix constant. Then all the queries need to > > > be changed to use the new constants -- instead of "select from auth_user > > > ..." it would be "select from ".USER_TABLE." ... > > > > Why not one constant for the prefix that is used in all queries? > > That's an alternative... let me let it roll around in my head a bit > > > > > The other suggestion from Javier sounds good, too, but I think it is not > > necessary. I think an array is a bit overloaded, isn't it? > > Hmm, I didn't see a suggestion from Javier -- either I missed it or he didn't send it to the list. :) > > > > > > If you'd like to do this I can add you to the project as a developer. > > > > ok, I would do this, just add me! > > You've been added > > > > > > It doesn't have to be right away, but it would also be nice to have this > > > prefix configurable via the configure script and have that script change > > > the db schema file accordingly. > > > > gonna see, what I can do. :) > > > > Cool! And, welcome aboard! > > _______________________________________________ > phpbt-dev mailing list > php...@li... > http://lists.sourceforge.net/lists/listinfo/phpbt-dev |
|
From: Patrick M. <mai...@st...> - 2001-08-29 17:19:50
|
On Wed, 29 Aug 2001, Ben Curtis wrote: > As promised, I've rolled it around in my head a bit, and I think I would like to have a constant for the prefix and a constant for each table name. This would allow for a prefix or not, and would allow people who prefer StudlyCaps table names to have them. And since we would be editing every query for the prefix constant anyway, we might as well use table name constants. > > Thoughts? I had the same thoughts yesterday, so I agree! :) |
|
From: Javier S. <js...@si...> - 2001-08-29 17:24:43
|
I think it's a good thing to have the abilty to tune each table name ;-) Ben Curtis wrote: >As promised, I've rolled it around in my head a bit, and I think I would like to have a constant for the prefix and a constant for each table name. This would allow for a prefix or not, and would allow people who prefer StudlyCaps table names to have them. And since we would be editing every query for the prefix constant anyway, we might as well use table name constants. > >Thoughts? > >On Tue, Aug 28, 2001 at 01:45:40PM -0700, Ben Curtis wrote: > >>On Tue, Aug 28, 2001 at 10:35:56PM +0200, Patrick Mairif wrote: >> >>>On Tue, 28 Aug 2001, Ben Curtis wrote: >>> >>>>What should happen is that a constant is added to config.php for the >>>>table name prefix, like phpbt_. Then constants need to be added for >>>>each table name using the prefix constant. Then all the queries need to >>>>be changed to use the new constants -- instead of "select from auth_user >>>>..." it would be "select from ".USER_TABLE." ... >>>> >>>Why not one constant for the prefix that is used in all queries? >>> >>That's an alternative... let me let it roll around in my head a bit >> >>>The other suggestion from Javier sounds good, too, but I think it is not >>>necessary. I think an array is a bit overloaded, isn't it? >>> >>Hmm, I didn't see a suggestion from Javier -- either I missed it or he didn't send it to the list. :) >> >>>> If you'd like to do this I can add you to the project as a developer. >>>> >>>ok, I would do this, just add me! >>> >>You've been added >> >>>>It doesn't have to be right away, but it would also be nice to have this >>>>prefix configurable via the configure script and have that script change >>>>the db schema file accordingly. >>>> >>>gonna see, what I can do. :) >>> >>Cool! And, welcome aboard! >> >>_______________________________________________ >>phpbt-dev mailing list >>php...@li... >>http://lists.sourceforge.net/lists/listinfo/phpbt-dev >> > >_______________________________________________ >phpbt-dev mailing list >php...@li... >http://lists.sourceforge.net/lists/listinfo/phpbt-dev > |
|
From: Patrick M. <mai...@st...> - 2001-08-29 18:56:12
|
I found a construct in bug.php (line 81) in which the old tablenames are used to access table fields in a loop, so I need a way to dynamically map the old names to the new configured ones, a hash for instance. So I would prefer Javiers solution and use one global hash and one constant for the prefix. At this point I need it anyway. Other ideas? |
|
From: Ben C. <php...@be...> - 2001-08-29 20:04:43
|
Argh, some of my own code foiling my plans... :) For this case we really need to have the TABLE_PREFIX (if that's the constant) be separate from xxx_TABLE or $TABLE['xxx'] (depending on whether we use a constant or hash (if you think of them as roughly equivalent (which the developer purist in me doesn't, but I digress (ooh the parentheses nesting)))). So that means that queries throughout the code will either look like "select * from ". PREFIX ."table where ..." or "select * from ". PREFIX.xxx_TABLE ." where ..." or "select * from ". PREFIX.$TABLE['xxx'] ." where ...". That way you have the PREFIXless table names for this array. Now as for the hash vs. constant decision, I really prefer constants for two reasons: 1. These values are constant, so by definition they should be constants. :) 2. If it's a variable you have to remember to global $TABLE almost everywhere in the code. Since I almost always forget to global $STRING when I need to, this one is a big deal for me. :) So, even though the query lines are going to get noticeably longer, I prefer to set up TABLE_PREFIX and xxx_TABLE constants (e.g, define(USER_TABLE, 'auth_user')) and then have queries like "select * from ". TABLE_PREFIX.USER_TABLE ." where user_id = blah". Comments? Revilings? Letters to CAP_ABUSE@? :) On Wed, Aug 29, 2001 at 08:56:03PM +0200, Patrick Mairif wrote: > I found a construct in bug.php (line 81) in which the old tablenames are > used to access table fields in a loop, so I need a way to dynamically map > the old names to the new configured ones, a hash for instance. So I would > prefer Javiers solution and use one global hash and one constant for the > prefix. At this point I need it anyway. > > Other ideas? |
|
From: Javier S. <js...@si...> - 2001-08-29 20:35:43
|
Ben Curtis wrote: >Argh, some of my own code foiling my plans... :) For this case we really need to have the TABLE_PREFIX (if that's the constant) be separate from xxx_TABLE or $TABLE['xxx'] (depending on whether we use a constant or hash (if you think of them as roughly equivalent (which the developer purist in me doesn't, but I digress (ooh the parentheses nesting)))). So that means that queries throughout the code will either look like "select * from ". PREFIX ."table where ..." or "select * from ". PREFIX.xxx_TABLE ." where ..." or "select * from ". PREFIX.$TABLE['xxx'] ." where ...". That way you have the PREFIXless table names for this array. > >Now as for the hash vs. constant decision, I really prefer constants for two reasons: >1. These values are constant, so by definition they should be constants. :) > ok :-) the global variable is not very intersting for constants :-P > >2. If it's a variable you have to remember to global $TABLE almost everywhere in the code. Since I almost always forget to global $STRING when I need to, this one is a big deal for me. :) > >So, even though the query lines are going to get noticeably longer, I prefer to set up TABLE_PREFIX and xxx_TABLE constants (e.g, define(USER_TABLE, 'auth_user')) and then have queries like "select * from ". TABLE_PREFIX.USER_TABLE ." where user_id = blah". > I will follow you ;-) > >Comments? Revilings? Letters to CAP_ABUSE@? :) > >On Wed, Aug 29, 2001 at 08:56:03PM +0200, Patrick Mairif wrote: > >>I found a construct in bug.php (line 81) in which the old tablenames are >>used to access table fields in a loop, so I need a way to dynamically map >>the old names to the new configured ones, a hash for instance. So I would >>prefer Javiers solution and use one global hash and one constant for the >>prefix. At this point I need it anyway. >> >>Other ideas? >> > >_______________________________________________ >phpbt-dev mailing list >php...@li... >http://lists.sourceforge.net/lists/listinfo/phpbt-dev > |
|
From: Ben C. <php...@be...> - 2001-08-29 20:51:37
|
Oh, I did leave out the alternative of having two sets of names... P_xxx_TABLE has the TABLE_PREFIX prepended and xxx_TABLE does not. That would avoid TABLE_PREFIX. showing up everywhere in the code. On Wed, Aug 29, 2001 at 10:36:50PM +0200, Javier Sixto wrote: > Ben Curtis wrote: > > >Argh, some of my own code foiling my plans... :) For this case we really > >need to have the TABLE_PREFIX (if that's the constant) be separate from > >xxx_TABLE or $TABLE['xxx'] (depending on whether we use a constant or hash > >(if you think of them as roughly equivalent (which the developer purist in > >me doesn't, but I digress (ooh the parentheses nesting)))). So that means > >that queries throughout the code will either look like "select * from ". > >PREFIX ."table where ..." or "select * from ". PREFIX.xxx_TABLE ." where > >..." or "select * from ". PREFIX.$TABLE['xxx'] ." where ...". That way you > >have the PREFIXless table names for this array. > > > >Now as for the hash vs. constant decision, I really prefer constants for > >two reasons: > >1. These values are constant, so by definition they should be constants. :) > > > ok :-) the global variable is not very intersting for constants :-P > > > > >2. If it's a variable you have to remember to global $TABLE almost > >everywhere in the code. Since I almost always forget to global $STRING > >when I need to, this one is a big deal for me. :) > > > >So, even though the query lines are going to get noticeably longer, I > >prefer to set up TABLE_PREFIX and xxx_TABLE constants (e.g, > >define(USER_TABLE, 'auth_user')) and then have queries like "select * from > >". TABLE_PREFIX.USER_TABLE ." where user_id = blah". > > > I will follow you ;-) > > > > >Comments? Revilings? Letters to CAP_ABUSE@? :) > > > >On Wed, Aug 29, 2001 at 08:56:03PM +0200, Patrick Mairif wrote: > > > >>I found a construct in bug.php (line 81) in which the old tablenames are > >>used to access table fields in a loop, so I need a way to dynamically map > >>the old names to the new configured ones, a hash for instance. So I would > >>prefer Javiers solution and use one global hash and one constant for the > >>prefix. At this point I need it anyway. > >> > >>Other ideas? > >> > > > >_______________________________________________ > >phpbt-dev mailing list > >php...@li... > >http://lists.sourceforge.net/lists/listinfo/phpbt-dev > > > > > > > _______________________________________________ > phpbt-dev mailing list > php...@li... > http://lists.sourceforge.net/lists/listinfo/phpbt-dev |
|
From: Patrick M. <mai...@st...> - 2001-08-30 08:04:19
|
I allready started a solution with an constant prefix and an array:
define ('DB_PREFIX', 'phpbt_');
$cfgDatabase['attachment'] = DB_PREFIX.'attachment');
the solution with only one prefix used everywhere would be another
possibility.
> Now as for the hash vs. constant decision, I really prefer constants for two
> reasons:
> 1. These values are constant, so by definition they should be constants. :)
> 2. If it's a variable you have to remember to global $TABLE almost
> everywhere in the code. Since I almost always forget to global $STRING
> when I need to, this one is a big deal for me. :)
I made the same experience! now, there is everywhere a
'global $cfgDatabase'! :-)
> So, even though the query lines are going to get noticeably longer, I
> prefer to set up TABLE_PREFIX and xxx_TABLE constants (e.g,
> define(USER_TABLE, 'auth_user')) and then have queries like "select *
> from ". TABLE_PREFIX.USER_TABLE ." where user_id = blah".
I need a dynamic mapping from the old tablenames, which are part of
fieldnames, to the new tablenames. I need a construct like
$cfgDatabase[$field]. With constants I have to create this kind of array
from the constants!
|
|
From: Patrick M. <mai...@st...> - 2001-08-30 14:12:46
|
I thought again about it and decided to use constants in general and create an array when needed. is this ok? |
|
From: Ben C. <php...@be...> - 2001-08-30 15:20:36
|
Heh, sounds good -- let me know if you need anymore completely biased opionion. :) On Thu, Aug 30, 2001 at 04:12:39PM +0200, Patrick Mairif wrote: > I thought again about it and decided to use constants in general and > create an array when needed. is this ok? > > > _______________________________________________ > phpbt-dev mailing list > php...@li... > http://lists.sourceforge.net/lists/listinfo/phpbt-dev |