Menu
▾
▴
phpwebsite-developers — For our development team.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
(1) |
Mar
(265) |
Apr
(166) |
May
(25) |
Jun
(17) |
Jul
(20) |
Aug
(47) |
Sep
(6) |
Oct
(14) |
Nov
(66) |
Dec
(64) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(109) |
Feb
(64) |
Mar
(34) |
Apr
(23) |
May
(64) |
Jun
(9) |
Jul
(13) |
Aug
(6) |
Sep
(33) |
Oct
(272) |
Nov
(67) |
Dec
(75) |
| 2003 |
Jan
(264) |
Feb
(244) |
Mar
(171) |
Apr
(119) |
May
(54) |
Jun
(93) |
Jul
(51) |
Aug
(48) |
Sep
(14) |
Oct
(49) |
Nov
(47) |
Dec
(15) |
| 2004 |
Jan
(13) |
Feb
(27) |
Mar
(18) |
Apr
(44) |
May
(35) |
Jun
(24) |
Jul
(39) |
Aug
(142) |
Sep
(35) |
Oct
(34) |
Nov
(49) |
Dec
(24) |
| 2005 |
Jan
(60) |
Feb
(71) |
Mar
(19) |
Apr
(27) |
May
(68) |
Jun
(4) |
Jul
(30) |
Aug
(10) |
Sep
(23) |
Oct
(24) |
Nov
(13) |
Dec
(6) |
| 2006 |
Jan
(4) |
Feb
(46) |
Mar
(64) |
Apr
(18) |
May
(16) |
Jun
(37) |
Jul
(7) |
Aug
(19) |
Sep
(9) |
Oct
(8) |
Nov
(3) |
Dec
(23) |
| 2007 |
Jan
(25) |
Feb
(21) |
Mar
(32) |
Apr
(36) |
May
(12) |
Jun
(1) |
Jul
(7) |
Aug
(15) |
Sep
(13) |
Oct
(1) |
Nov
|
Dec
|
| 2008 |
Jan
(3) |
Feb
(5) |
Mar
(1) |
Apr
(2) |
May
|
Jun
(1) |
Jul
(2) |
Aug
(7) |
Sep
|
Oct
(5) |
Nov
(1) |
Dec
|
| 2009 |
Jan
(7) |
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(3) |
| 2011 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Matthew M. <ma...@tu...> - 2002-10-23 13:27:47
|
> I share Don's concern... I think we should be very careful in regards to > performance issues - the DB abstraction *will* slow things down a bit no > matter how well it is implemented. To further this point: Database abstraction will get better. PEAR is still pretty green (heh), not in skill and talent obviously, but in age and acceptance. They WILL become the predominate library for php and we should take advantage of it. As they grow, we grow. Plus their abstraction code will probably get tighter and faster. As for the question as to why should we support many databases. Our goal is to make phpWebSite THE platform to program for. Instead of focusing on the "gee whiz", we focus on flexibility, standard, and easy of use. This draws developers which allows us to grow. More database options, means better chances for module creation. Why limit ourselves to people who just know MySQL when we can pull developers from seven other databases? Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 |
|
From: Matthew M. <ma...@tu...> - 2002-10-23 13:15:29
|
> My employer blocks the cvs port. > > Any chance of providing a daily cvs tarball of the 3 fallout trees > (core,mod,themes)? Our PR dept wants an intranet website and I have > them sold on phpWS but I'd rather do it with 0.9 than 0.8. Yes, I believe Jagee is going to set up a cron for that. We'll keep you posted. Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Matthew M. <ma...@tu...> - 2002-10-23 13:14:15
|
Cool. Thanks for the heads up. Now only if we could get our CVS commits to count on Sourceforge... Matt > Everyone, > This is great news. SourceForge is making forums available from a nntp > news server, and is planning to make mailing lists available too. > > > On Mon, 2002-10-21 at 23:33, SourceForge.netTeam wrote: >> 4. NNTP Beta Test >> -------------------------- >> >> Today we are launching an early beta release of a new feature on >> SourceForge.net. This feature makes it possible to view and post data >> to forums using a simple newsreader (exactly like using USENET >> newsgroups). Here's the information to login and try it out. >> >> The hostname of the NNTP server is 'nntp.sourceforge.net' and the port >> NNTP is listening on is 563. (nntps, SSL-protected NNTP) >> >> We allow only SSL connections. >> >> You need to use your SourceForge user name and password to login. >> >> The currently supported clients are Mozilla and Outlook, however we've >> followed the NNTP RFC; any client that does NNTP over SSL /should/ >> work. Please let us know if you have problems with a specific client. >> (Please see below) >> >> Posting works, with one caveat: to limit SPAM we limit the amount of >> posts to 10 in a 5 minute period, after which we deny posting for some >> time for that user account. >> >> NOTE: This is real data. Posts will show up in your forums! >> >> Please keep this in mind. >> >> Here is an example of the NNTP naming we've chosen, it is much like >> the project web tree. "sf.a.al.alexandria.open_discussion" will get >> you the "Open Discussion" forum for project "alexandria". >> >> Mailing lists are currently _not_ available but will be available in >> the near future. >> >> If you would like to report bugs, ideas, or anything else please >> subscribe to the beta mailing list at: >> >> https://lists.sourceforge.net/lists/listinfo/mcgoo-nttpbeta >> >> Please keep in mind that the server is beta and will more than likely >> crash. Please don't send 1000 emails to list saying the server is >> offline; we'll fix it as soon as we get a chance. Please send any bug >> reports, odd behavior, or problems to this list. Thank you. >> Issue reports regarding this new beta feature should not be submitted >> as Support Requests; please direct all inquiries to the list. > > -- > Mike Noyes <mh...@us...> > http://sourceforge.net/users/mhnoyes/ > http://leaf-project.org/ > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Brian W. B. <br...@tu...> - 2002-10-23 13:13:04
|
>> I'm just paranoid of dead-locks and bottlenecks by having one table
>> store all sequences.
> Yes, we didn't think about that. Good that it was pointed out early :)
I share Don's concern... I think we should be very careful in regards to
performance issues - the DB abstraction *will* slow things down a bit no
matter how well it is implemented. But a single table for all sequences
sounds like a real bottleneck, especially with locks being thrown...
My 2 cents...
Brian
--
Brian W. Brown
Director, Electronic Student Services
Student Development
Room 269, John Thomas Hall
Appalachian State University
Boone, NC 28608
vox: 828-262-7124
fax: 828-262-2585
L I N U X
.~.
/V\
// \\
/( )\
^^-^^
Love the Penguin
|
|
From: Matthew M. <ma...@tu...> - 2002-10-23 12:57:01
|
> I'm just paranoid of dead-locks and bottlenecks by having one table > store all sequences. > > Don. Yes, we didn't think about that. Good that it was pointed out early :) It is in CVS now. Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Matthew M. <ma...@tu...> - 2002-10-23 12:55:52
|
> PEAR standard for which? Sequencing Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Don S. <do...@se...> - 2002-10-22 19:54:22
|
I don't think this is too much of a burden on the user, since they would have to create the mysql user account anyway. Creating the database is actually and easier command, IMHO. I think providing the commands to create the necessary items would be good. Don. On Tue, 22 Oct 2002, Matthew McNaney wrote: > Unfortunately, the list of things that differ between MySQL and other > databases begins to grow. > > PostGRE requires a database to connect. This database is connected with > the username of the PostGRE account. > > What this means is that you can't connect, and then create a database as > you can with MySQL. So that functionality is probably going to be removed > from the setup. It will instead tell the user they must create a database > before continuing installation. > > We also talked about ways we could make this easier on the user. We could, > perhaps, echo instructions on how to create the database in their > respective db choice. > > We shall see tomorrow as we try to get a PostGRE install to run. > > > Matthew McNaney > Internet Systems Architect > Electronic Student Services > Email: ma...@tu... > URL: http://phpwebsite.appstate.edu > Phone: 828-262-6493 > ICQ: 141057403 > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Matthew M. <ma...@tu...> - 2002-10-22 19:49:11
|
Unfortunately, the list of things that differ between MySQL and other databases begins to grow. PostGRE requires a database to connect. This database is connected with the username of the PostGRE account. What this means is that you can't connect, and then create a database as you can with MySQL. So that functionality is probably going to be removed from the setup. It will instead tell the user they must create a database before continuing installation. We also talked about ways we could make this easier on the user. We could, perhaps, echo instructions on how to create the database in their respective db choice. We shall see tomorrow as we try to get a PostGRE install to run. Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Don S. <do...@se...> - 2002-10-22 19:08:19
|
My employer blocks the cvs port. Any chance of providing a daily cvs tarball of the 3 fallout trees (core,mod,themes)? Our PR dept wants an intranet website and I have them sold on phpWS but I'd rather do it with 0.9 than 0.8. Just curious, Don. |
|
From: Don S. <do...@se...> - 2002-10-22 19:03:26
|
Thanks. Perhaps the phpWS team wants to do some updated benchmarking tests if they have the time. ;) Sorry if I sounded caustic before. It just appeared to me that you were throwing around statements without any backing, troll-style. Thanks again, Don. On Tue, 22 Oct 2002, Eloi George wrote: > > I guess what you "think" doesn't count for much. > > <chuckle> You're right, it doesn't. When I say "I think", what I'm actually > saying is that I'm making a totally unqualified guess and I'm hoping that > someone else who knows the answer would step up. Incidentally, I just found > a post at http://www.phpbuilder.net/annotate/message.php3?id=1002047 which > said that 200 queries/sec is doable. So I was wrong on that assumption. > > >I would require valid > > numbers. I'll assume you are using mysql with postnuke. Have you tested > > with postgres or mssql or oracle or anything else? It doesn't sound like > > it. > > I guess I forgot to mention that that is -not- my site. It was a heavy-use > site mentioned in a post on postnuke.com back in August. I have no idea > what the db backend is. For all I know the stats page could have been made > up to sell advertising. That's why I used it as a -representation- of what > we hope to acheive with our own sites. > > There is a benchmarking suite available on the PEAR site. An old benchmark > summary found on http://www.phplens.com/lens/adodb/ indicated a 152-176% > overhead. Of course results will vary on different configurations & > versions. <grin> > > -Eloi- > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Eloi G. <el...@re...> - 2002-10-22 18:57:30
|
> I guess what you "think" doesn't count for much. <chuckle> You're right, it doesn't. When I say "I think", what I'm actually saying is that I'm making a totally unqualified guess and I'm hoping that someone else who knows the answer would step up. Incidentally, I just found a post at http://www.phpbuilder.net/annotate/message.php3?id=1002047 which said that 200 queries/sec is doable. So I was wrong on that assumption. >I would require valid > numbers. I'll assume you are using mysql with postnuke. Have you tested > with postgres or mssql or oracle or anything else? It doesn't sound like > it. I guess I forgot to mention that that is -not- my site. It was a heavy-use site mentioned in a post on postnuke.com back in August. I have no idea what the db backend is. For all I know the stats page could have been made up to sell advertising. That's why I used it as a -representation- of what we hope to acheive with our own sites. There is a benchmarking suite available on the PEAR site. An old benchmark summary found on http://www.phplens.com/lens/adodb/ indicated a 152-176% overhead. Of course results will vary on different configurations & versions. <grin> -Eloi- |
|
From: Don S. <do...@se...> - 2002-10-22 17:05:54
|
I guess what you "think" doesn't count for much. I would require valid numbers. I'll assume you are using mysql with postnuke. Have you tested with postgres or mssql or oracle or anything else? It doesn't sound like it. I personally would want real evidence of quasi-scientific testing. Just setting up a page to directly call the mysql functions and then make those calls through PEAR is enough. Perhaps the PEAR folks have done such things... Don. On Tue, 22 Oct 2002, Eloi George wrote: > www.actionfigure.com is actually a postnuke site, but is a pretty good > representation of what we may hope that one of our (or our client's) sites > can achieve. Looking at his stats at > http://www.action-figure.com/modules.php?op=modload&name=Stats&file=index it > looks like the site has averaged 570,000 hits per month for the last 9 > months. That's 13 hits per second. > > Postnuke doesn't have any load-balancing features, so all this is handled on > one server. If we don't count the main page (13 modules), the average page > on the site looks like it uses 6 modules including banner rotations & user > stats. If we assume just 1 query per module, then we end up with an average > of 78 queries per second! > > Hmm. I don't think any db's can handle that much... > > -Eloi- > > ----- Original Message ----- > From: "Don Seiler" <do...@se...> > To: "Eloi George" <el...@re...> > Cc: <ma...@tu...>; <php...@li...> > Sent: Tuesday, October 22, 2002 10:49 AM > Subject: Re: [Phpwebsite-developers] PEAR DB and auto_increment > > > > > I know I'm coming in too late in the game, but it'd be great if phpWS > didn't > > > try to support every db in the known world. That way there wouldn't be > a > > > bunch of middle-layer generalized db access protocols to slow everything > > > down. > > > > If we use the PEAR standards, then phpWS doesn't need to worry about > > supporting things, the PEAR team will have done all that legwork, and I'm > > confident that the PEAR team will have done it the most efficient way > > possible. > > > > Even if phpWS only wanted to support two or three, once you support more > > than one you might as well use PEAR and support them all, rather than > > write the functions yourself. > > > > I'd be interested in seeing some benchmarks about how the pear DB layer > > affects performance. I don't think the hit would be that bad. What is > > the largest scale site running phpWS, btw? > > > > Don. > > > > > > > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Eloi G. <el...@re...> - 2002-10-22 16:58:08
|
www.actionfigure.com is actually a postnuke site, but is a pretty good representation of what we may hope that one of our (or our client's) sites can achieve. Looking at his stats at http://www.action-figure.com/modules.php?op=modload&name=Stats&file=index it looks like the site has averaged 570,000 hits per month for the last 9 months. That's 13 hits per second. Postnuke doesn't have any load-balancing features, so all this is handled on one server. If we don't count the main page (13 modules), the average page on the site looks like it uses 6 modules including banner rotations & user stats. If we assume just 1 query per module, then we end up with an average of 78 queries per second! Hmm. I don't think any db's can handle that much... -Eloi- ----- Original Message ----- From: "Don Seiler" <do...@se...> To: "Eloi George" <el...@re...> Cc: <ma...@tu...>; <php...@li...> Sent: Tuesday, October 22, 2002 10:49 AM Subject: Re: [Phpwebsite-developers] PEAR DB and auto_increment > > I know I'm coming in too late in the game, but it'd be great if phpWS didn't > > try to support every db in the known world. That way there wouldn't be a > > bunch of middle-layer generalized db access protocols to slow everything > > down. > > If we use the PEAR standards, then phpWS doesn't need to worry about > supporting things, the PEAR team will have done all that legwork, and I'm > confident that the PEAR team will have done it the most efficient way > possible. > > Even if phpWS only wanted to support two or three, once you support more > than one you might as well use PEAR and support them all, rather than > write the functions yourself. > > I'd be interested in seeing some benchmarks about how the pear DB layer > affects performance. I don't think the hit would be that bad. What is > the largest scale site running phpWS, btw? > > Don. > > > |
|
From: Steven L. <st...@tu...> - 2002-10-22 15:32:01
|
Installing with a table prefix is broken :( > I commited the PEAR standard back with these changes: > > sqlImport does not create the sequence table anymore as the creation > automatically adds a 1 (ie the next insert is slotted to 2). > > This means any inserts in your install.sql will need to have their id's > set (for now until I rewrite the import function) > > sqlInsert still does not require a column name for sequencing. It will > detect it automatically. So a standard insert now looks like: > $core->sqlInsert($row_values, "table_name"); > > If a PRIMARY index exists, it becomes the column name. If one doesn't > exist, then the sequencer is skipped altogether. > > Lock rules still apply. Don't lock a table before you go into the > insert. > > > I have performed an install and everything APPEARS ok. Let me know if > you find anything. Also, if someone can test other databases, please do > so. > > Later, > Matt > > Matthew McNaney > Internet Systems Architect > Electronic Student Services > Email: ma...@tu... > URL: http://phpwebsite.appstate.edu > Phone: 828-262-6493 > ICQ: 141057403 > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Steven Levin Electronic Student Services Appalachian State University Phone: 828.262.2431 PhpWebsite Development Team URL: http://phpwebsite.appstate.edu Email: st...@NO... |
|
From: Darrel <da...@ii...> - 2002-10-22 15:13:19
|
You may want to take a look at this paper by Scott Ambler[1]. It compares the various approaches to getting an object identifier and then suggests an alternative called the high/low approach that might work well in your situation. The big differences are that he uses a single sequence for all objects and he allocates a set of id's to a session so that a database access is not required on each object allocation, only when the set of assigned ID's is used up. Darrel [1] http://www.ambysoft.com/mappingObjects.pdf > -----Original Message----- > From: php...@li... > [mailto:php...@li...] On > Behalf Of Don Seiler > Sent: October 22, 2002 10:43 AM > To: Steven Levin > Cc: php...@li... > Subject: Re: [Phpwebsite-developers] Sequence Tables > > > So we're going with the pear sequences and the additional > *_seq tables? > > I'll go +1 on that. > > I'm just paranoid of dead-locks and bottlenecks by having one > table store > all sequences. > > Don. > > On Tue, 22 Oct 2002, Steven Levin wrote: > > > Hello All, > > > > In response to the very long thread we have had concerning > the PEAR DB > > and auto_increment, the development team just held a meeting to > > discuss our options. The decision was made to stick with the PEAR > > standards. > > > > So here is my +1 > > > > Please vote :) > > > > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun .com/javavote _______________________________________________ Phpwebsite-developers mailing list Php...@li... https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers |
|
From: Matthew M. <ma...@tu...> - 2002-10-22 15:05:14
|
I commited the PEAR standard back with these changes: sqlImport does not create the sequence table anymore as the creation automatically adds a 1 (ie the next insert is slotted to 2). This means any inserts in your install.sql will need to have their id's set (for now until I rewrite the import function) sqlInsert still does not require a column name for sequencing. It will detect it automatically. So a standard insert now looks like: $core->sqlInsert($row_values, "table_name"); If a PRIMARY index exists, it becomes the column name. If one doesn't exist, then the sequencer is skipped altogether. Lock rules still apply. Don't lock a table before you go into the insert. I have performed an install and everything APPEARS ok. Let me know if you find anything. Also, if someone can test other databases, please do so. Later, Matt Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Don S. <do...@se...> - 2002-10-22 14:50:00
|
> I know I'm coming in too late in the game, but it'd be great if phpWS didn't > try to support every db in the known world. That way there wouldn't be a > bunch of middle-layer generalized db access protocols to slow everything > down. If we use the PEAR standards, then phpWS doesn't need to worry about supporting things, the PEAR team will have done all that legwork, and I'm confident that the PEAR team will have done it the most efficient way possible. Even if phpWS only wanted to support two or three, once you support more than one you might as well use PEAR and support them all, rather than write the functions yourself. I'd be interested in seeing some benchmarks about how the pear DB layer affects performance. I don't think the hit would be that bad. What is the largest scale site running phpWS, btw? Don. |
|
From: Adam M. <ad...@tu...> - 2002-10-22 14:49:26
|
OK after meeting with everyone here I've decided to change my vote to sticking with the PEAR standard. This will require more tables but will also reduce the "bottleneck" effect. So...+1 on PEAR standard Adam > I'm with the single table idea for all sequence numbers. > > This way we can have one select on init that loads all sequence numbers > into a session array. Then on inserts we only have to update the > core_sequencer table instead of select AND update it (thinking of > reducing database accesses). > > Also, with all the sequence numbers in the core table, we can get rid of > the current _seq tables getting our table total back down to around 23 > :) (organizational +). > > Another plus? A quick re-write of the sqlmaxid function can simply > return the id in the sessioned sequence array (less database > action=good...there may be more functions that can take advantage). > > We can continue to rely on the pear package, we just need to try and get > the best of all worlds. > > Adam > > --------------------------------- > Adam Morton > Developer - Web Technology Group > Appalachian State University > http://phpwebsite.appstate.edu > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers --------------------------------- Adam Morton Developer - Web Technology Group Appalachian State University http://phpwebsite.appstate.edu |
|
From: Don S. <do...@se...> - 2002-10-22 14:43:34
|
So we're going with the pear sequences and the additional *_seq tables? I'll go +1 on that. I'm just paranoid of dead-locks and bottlenecks by having one table store all sequences. Don. On Tue, 22 Oct 2002, Steven Levin wrote: > Hello All, > > In response to the very long thread we have had concerning the PEAR DB > and auto_increment, the development team just held a meeting to discuss > our options. The decision was made to stick with the PEAR standards. > > So here is my +1 > > Please vote :) > > |
|
From: Steven L. <st...@tu...> - 2002-10-22 14:37:00
|
Hello All, In response to the very long thread we have had concerning the PEAR DB and auto_increment, the development team just held a meeting to discuss our options. The decision was made to stick with the PEAR standards. So here is my +1 Please vote :) -- Steven Levin Electronic Student Services Appalachian State University Phone: 828.262.2431 PhpWebsite Development Team URL: http://phpwebsite.appstate.edu Email: st...@NO... |
|
From: Don S. <do...@se...> - 2002-10-22 14:28:34
|
PEAR standard for which? Don. On Tue, 22 Oct 2002, Matthew McNaney wrote: > I have decided to vote for PEAR standard +1 > > Matt > > > Matthew McNaney > Internet Systems Architect > Electronic Student Services > Email: ma...@tu... > URL: http://phpwebsite.appstate.edu > Phone: 828-262-6493 > ICQ: 141057403 > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576301;v?http://www.sun.com/javavote > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers > |
|
From: Matthew M. <ma...@tu...> - 2002-10-22 14:23:39
|
I have decided to vote for PEAR standard +1 Matt Matthew McNaney Internet Systems Architect Electronic Student Services Email: ma...@tu... URL: http://phpwebsite.appstate.edu Phone: 828-262-6493 ICQ: 141057403 |
|
From: Mike N. <mh...@us...> - 2002-10-22 14:16:01
|
Everyone, This is great news. SourceForge is making forums available from a nntp news server, and is planning to make mailing lists available too. On Mon, 2002-10-21 at 23:33, SourceForge.netTeam wrote: > 4. NNTP Beta Test > -------------------------- > > Today we are launching an early beta release of a new feature on > SourceForge.net. This feature makes it possible to view and post data > to forums using a simple newsreader (exactly like using USENET > newsgroups). Here's the information to login and try it out. > > The hostname of the NNTP server is 'nntp.sourceforge.net' and the port > NNTP is listening on is 563. (nntps, SSL-protected NNTP) > > We allow only SSL connections. > > You need to use your SourceForge user name and password to login. > > The currently supported clients are Mozilla and Outlook, however we've > followed the NNTP RFC; any client that does NNTP over SSL /should/ > work. Please let us know if you have problems with a specific client. > (Please see below) > > Posting works, with one caveat: to limit SPAM we limit the amount of > posts to 10 in a 5 minute period, after which we deny posting for some > time for that user account. > > NOTE: This is real data. Posts will show up in your forums! > > Please keep this in mind. > > Here is an example of the NNTP naming we've chosen, it is much like > the project web tree. "sf.a.al.alexandria.open_discussion" will get > you the "Open Discussion" forum for project "alexandria". > > Mailing lists are currently _not_ available but will be available in > the near future. > > If you would like to report bugs, ideas, or anything else please > subscribe to the beta mailing list at: > > https://lists.sourceforge.net/lists/listinfo/mcgoo-nttpbeta > > Please keep in mind that the server is beta and will more than likely > crash. Please don't send 1000 emails to list saying the server is > offline; we'll fix it as soon as we get a chance. Please send any bug > reports, odd behavior, or problems to this list. Thank you. > Issue reports regarding this new beta feature should not be submitted > as Support Requests; please direct all inquiries to the list. -- Mike Noyes <mh...@us...> http://sourceforge.net/users/mhnoyes/ http://leaf-project.org/ |
|
From: Steven L. <st...@tu...> - 2002-10-22 13:49:13
|
+1 to one table. > I'm with the single table idea for all sequence numbers. > > This way we can have one select on init that loads all sequence numbers > into a session array. Then on inserts we only have to update the > core_sequencer table instead of select AND update it (thinking of > reducing database accesses). > > Also, with all the sequence numbers in the core table, we can get rid of > the current _seq tables getting our table total back down to around 23 > :) (organizational +). > > Another plus? A quick re-write of the sqlmaxid function can simply > return the id in the sessioned sequence array (less database > action=good...there may be more functions that can take advantage). > > We can continue to rely on the pear package, we just need to try and get > the best of all worlds. > > Adam > > --------------------------------- > Adam Morton > Developer - Web Technology Group > Appalachian State University > http://phpwebsite.appstate.edu > > > > > ------------------------------------------------------- > This sf.net emial is sponsored by: Influence the future > of Java(TM) technology. Join the Java Community > Process(SM) (JCP(SM)) program now. > http://ad.doubleclick.net/clk;4699841;7576298;k?http://www.sun.com/javavote > _______________________________________________ > Phpwebsite-developers mailing list > Php...@li... > https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers -- Steven Levin Electronic Student Services Appalachian State University Phone: 828.262.2431 PhpWebsite Development Team URL: http://phpwebsite.appstate.edu Email: st...@NO... |
|
From: Matthew M. <ma...@tu...> - 2002-10-22 13:38:21
|
Yes. The core functions originally were just helpful functions. They saved
a lot of time instead of having to use query("insert into .. etc") type
calls. Eventually we found them to be a great timesaver.
In fact, many of the functions in the core are timesavers. You don't have
to use them, but they make working with Fallout much easier.
Matt
> So the modules use the core's sqlInsert function for their own database
> transactions?
>
> Don.
>
> On Tue, 22 Oct 2002, Matthew McNaney wrote:
>
>> I forgot to mention. You will need the core_sequence table.
>>
>> Should install on setup. I have NOT removed the PEAR sequence from the
>> setup yet so you will get the _seq tables. I will remove them when
>> approved.
>>
>> Matt
>>
>>
>> Matthew McNaney
>> Internet Systems Architect
>> Electronic Student Services
>> Email: ma...@tu...
>> URL: http://phpwebsite.appstate.edu
>> Phone: 828-262-6493
>> ICQ: 141057403
>>
>>
>>
>>
>> -------------------------------------------------------
>> This sf.net emial is sponsored by: Influence the future of
>> Java(TM) technology. Join the Java Community Process(SM) (JCP(SM))
>> program now. http://ad.doubleclick.net/clk;4699841;7576301;v?
>> http://www.sun.com/javavote
>> _______________________________________________
>> Phpwebsite-developers mailing list
>> Php...@li...
>> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
>>
>
>
>
> -------------------------------------------------------
> This sf.net emial is sponsored by: Influence the future of
> Java(TM) technology. Join the Java Community Process(SM) (JCP(SM))
> program now. http://ad.doubleclick.net/clk;4699841;7576301;v?
> http://www.sun.com/javavote
> _______________________________________________
> Phpwebsite-developers mailing list
> Php...@li...
> https://lists.sourceforge.net/lists/listinfo/phpwebsite-developers
Matthew McNaney
Internet Systems Architect
Electronic Student Services
Email: ma...@tu...
URL: http://phpwebsite.appstate.edu
Phone: 828-262-6493
ICQ: 141057403
|
5 messages has been excluded from this view by a project administrator.
