You are. The community may benefit from Acquia's 'public' support/choice of contributed modules it in no way, shape or form establishes a 'gold' repository at drupal.org. Many companies have a suite of modules they commonly use and track, just don't make public that list.
Firstly - barring official announcements which I haven't seen, Dries nor Aqcuia have publicly stated that they *would* not help try to inject some sanity into upgrade/development cycles (e.g., making sure that certain contrib module's don't get left too far behind) Also, I never mentioned a 'gold' repository. My original intention was simply to sign on too the idea that catch suggested which I understood it was - 'why release a Drupal version that no one is going to use for any large/critical sites for six months (or possibly ever)'. In addition to myself, I know at least one other (large) shop that has more or less committed to skip Drupal 6. This is what's happening and no one wants to deal with it and just poo-poos such talk as being irrelevant. But it is happening, and it's up to everyone to form their own opinion of any relevancy. (personally I'm fine with the idea that some releases end up this way IF was more publicly acknowledge instead of hushed up, which is what I feel like is happening now to some extent) The real point of all this, which makes this discussion not just a pedantic exercise, is that I truly feel sorry for anyone starting up a big project right now who is just getting into Drupal and trying to make sense of what version to use. I've seen people giving others what I consider to be very bad advice and representing a state of stability/readiness for Drupal 6 which, in my considered *opinion*, is just not there. Regards, Caleb
Caleb Gilbert schrieb:
Also, I never mentioned a 'gold' repository. My original intention was simply to sign on too the idea that catch suggested which I understood it was - 'why release a Drupal version that no one is going to use for any large/critical sites for six months (or possibly ever)'.
In addition to myself, I know at least one other (large) shop that has more or less committed to skip Drupal 6. This is what's happening and no one wants to deal with it and just poo-poos such talk as being irrelevant. But it is happening, and it's up to everyone to form their own opinion of any relevancy. (personally I'm fine with the idea that some releases end up this way IF was more publicly acknowledge instead of hushed up, which is what I feel like is happening now to some extent)
Now you know another Drupal shop.
The real point of all this, which makes this discussion not just a pedantic exercise, is that I truly feel sorry for anyone starting up a big project right now who is just getting into Drupal and trying to make sense of what version to use. I've seen people giving others what I consider to be very bad advice and representing a state of stability/readiness for Drupal 6 which, in my considered *opinion*, is just not there.
I totally agree with you. D6 is a great release, but given these facts, we might consider to release Drupal core not by date, but when important modules in contrib are ready. I.e. what buys me a modular system, if there are only a few modules available? Thank you for this write-up; I couldn't have expressed it better, Daniel
On Apr 30, 2008, at 6:45 PM, Daniel F. Kudwien wrote:
D6 is a great release, but given these facts, we might consider to release Drupal core not by date, but when important modules in contrib are ready. I.e. what buys me a modular system, if there are only a few modules available?
I'm sorry but I think the idea of delaying Drupal 6 until - let's say Views - is ported, is nonsense. I understand that for a lot of people no Views makes Drupal 6 unusable, but this is not everybody. There are actually a lot of Drupal 6 sites that have already launched, and we have already released two point upgrades to the original 6.0. What kind of interest would there have been in finding the bugs that prompted 6.1 and 6.2 if it were *unreleased*? What is so wrong with waiting for contrib to catch up? This is a problem that you will never solve. As soon as Views is adequately in core and thus tied at the hip to core's release cycle, there will be another killer module that everybody comes to love, in contrib. It too will have to wait until a release to really finalize its porting. Now, if you as a business decide to skip D6 because Views isn't ready now (where it clearly will be in a small number of months, at the latest), you are effectively deciding to use outdated Drupal technology for most of a year, if not longer, until Drupal 7 is released. My guess is that the killer modules that add great value to Drupal 6 won't be all ported the day Drupal 7 is released, either, so you'll be stuck again. In case, I pity you for deciding not to do projects on Drupal 6 at all, and holding out for whatever you imagine Drupal 7 is going to be. I can't see how this will be an advantage for you. Furthermore, I don't see it as worrisome if people aren't rushing to do projects on D6 yet. They will. When Views and CCK and OG are all stable there will be a stampede to D6. The fact that this is separated from the release of D6 by some months is totally normal, in my opinion. Let Drupal 6 mature. Sure there are some things we can do to refine the process, but you just can't have it all at once. Not now, not ever. Learn some patience. -Robert
Quoting Robert Douglass <rob@robshouse.net>:
On Apr 30, 2008, at 6:45 PM, Daniel F. Kudwien wrote:
D6 is a great release, but given these facts, we might consider to release Drupal core not by date, but when important modules in contrib are ready. I.e. what buys me a modular system, if there are only a few modules available?
I'm sorry but I think the idea of delaying Drupal 6 until - let's say Views - is ported, is nonsense. I understand that for a lot of people no Views makes Drupal 6 unusable, but this is not everybody. There are actually a lot of Drupal 6 sites that have already launched, and we have already released two point upgrades to the original 6.0. What kind of interest would there have been in finding the bugs that prompted 6.1 and 6.2 if it were *unreleased*?
Hurray, statements I can agree with.
What is so wrong with waiting for contrib to catch up? This is a problem that you will never solve. As soon as Views is adequately in core and thus tied at the hip to core's release cycle, there will be another killer module that everybody comes to love, in contrib. It too will have to wait until a release to really finalize its porting.
If you can't wait pitch in and start working.
Now, if you as a business decide to skip D6 because Views isn't ready now (where it clearly will be in a small number of months, at the latest), you are effectively deciding to use outdated Drupal technology for most of a year, if not longer, until Drupal 7 is released. My guess is that the killer modules that add great value to Drupal 6 won't be all ported the day Drupal 7 is released, either, so you'll be stuck again. In case, I pity you for deciding not to do projects on Drupal 6 at all, and holding out for whatever you imagine Drupal 7 is going to be. I can't see how this will be an advantage for you.
Well, since skipping isn't a recommended process for an upgrade you might want to reconsider.
Furthermore, I don't see it as worrisome if people aren't rushing to do projects on D6 yet. They will. When Views and CCK and OG are all stable there will be a stampede to D6. The fact that this is separated from the release of D6 by some months is totally normal, in my opinion.
Yes, six months for contributions to catch up is a worthy goal. Six months for a lone sole with little time may be a bit short. Again if you need it, pitch in and help.
Let Drupal 6 mature. Sure there are some things we can do to refine the process, but you just can't have it all at once. Not now, not ever. Learn some patience.
Or learn PHP and the Drupal API so you can pitch in and help. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Wed, 30 Apr 2008 08:34:01 -0700 "Caleb Gilbert" <caleb.gilbert@gmail.com> wrote:
In addition to myself, I know at least one other (large) shop that has more or less committed to skip Drupal 6. This is what's happening and no one wants to deal with it and just poo-poos such talk as being irrelevant. But it is happening, and it's up to everyone to form their own opinion of any relevancy. (personally I'm fine with the
I can tell you for a fact that our customers are not jumping to 6. They are all on 5 and will remain there for the foreseeable future.
The real point of all this, which makes this discussion not just a pedantic exercise, is that I truly feel sorry for anyone starting up a big project right now who is just getting into Drupal and trying to make sense of what version to use. I've seen people giving others what I consider to be very bad advice and representing a state of stability/readiness for Drupal 6 which, in my considered *opinion*, is just not there.
I admit that I tend to stay on the database side of things and a lot of what I do is fix deficiencies in the Drupal model by moving them properly into the database and having Drupal called stored procedures etc.. but I can say that the customers that we deal with are sticking with 5 precisely because of the concerns on this thread. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Wed, 30 Apr 2008 09:45:46 -0700 "Joshua D. Drake" <jd@commandprompt.com> wrote:
I admit that I tend to stay on the database side of things and a lot of what I do is fix deficiencies in the Drupal model by moving them properly into the database and having Drupal called stored procedures etc.. but I can say that the customers that we deal with
Interesting. I'm doing the same but I haven't touched core to avoid a further burden in maintenance if I've to keep up with security updates. I think it would be enlightening to see where you exploited more advanced DB functions. Even if I suppose you did with one DB in mind it would still be interesting to know which were the features and where you thought they really fit because D7 should support much more DB features. Even if I doubt support for stored procedures is going to find its way into Drupal since the core has to remain DB agnostic and I think providing an abstraction layer to sp is hard some oversight may help to see which are the features that could be more relevant to support... I'm at least thinking to transactions. -- Ivan Sergio Borgonovo http://www.webthatworks.it
On Wed, 30 Apr 2008 19:06:24 +0200 Ivan Sergio Borgonovo <mail@webthatworks.it> wrote:
Interesting. I'm doing the same but I haven't touched core to avoid a further burden in maintenance if I've to keep up with security updates.
Well we try to stay out of that as well if we can but sometimes you just can't (like using Tsearch2).
I think it would be enlightening to see where you exploited more advanced DB functions. Even if I suppose you did with one DB in mind it would still be interesting to know which were the features and where you thought they really fit because D7 should support much more DB features.
Actually it should be fairly easy to do if the API is abstracted out correctly. The things I see needing to be done (and I admit that I haven't even looked at 7): * Abstract out page renders into custom calls. * So the node call checks to see if its predetermined (and thus draws whatever is in the db to draw), like the front page. * Or, if a node load exists (terminology as you like) it would call whatever you want. Case in point, Drupal can easily execute 200 queries to draw a page. Why do we do that? It's dumb and inefficient. You lose 30ms for every single query just in TCP negotiation. You push that to 5 stored procedures that draw blocks, and you have shaved ~ 5 seconds off your load in just negotiation. Add a cached procedure and you could shave another ~ 5 seconds off.
Even if I doubt support for stored procedures is going to find its way into Drupal since the core has to remain DB agnostic
I doubt that is actually an issue. I understand that we have to dumb things down for the dolphin but that doesn't mean the api can't be smart about it. If Catalyst can do it...
and I think providing an abstraction layer to sp is hard some oversight may help to see which are the features that could be more relevant to support... I'm at least thinking to transactions.
Ahh but it can. Remember that even the dolphin has stored procedures. Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
On Wed, 30 Apr 2008 10:25:13 -0700, "Joshua D. Drake" <jd@commandprompt.com> wrote:
Case in point, Drupal can easily execute 200 queries to draw a page. Why do we do that? It's dumb and inefficient. You lose 30ms for every single query just in TCP negotiation. You push that to 5 stored procedures that draw blocks, and you have shaved ~ 5 seconds off your load in just negotiation. Add a cached procedure and you could shave another ~ 5 seconds off.
My queries, according to dev module, are quite rarely more than 5 ms. I don't know where you're getting that 30 ms number from. And, AFAIK, an open SQL connection is a persistent TCP connection, therefore it only has to negotiate the connection once. MySQL is also really fast at that setup compared to most databases. I agree that reducing our query count is a good thing, but not because of a 30 ms overhead per query.
Even if I doubt support for stored procedures is going to find its way into Drupal since the core has to remain DB agnostic
I doubt that is actually an issue. I understand that we have to dumb things down for the dolphin but that doesn't mean the api can't be smart about it.
If Catalyst can do it...
and I think providing an abstraction layer to sp is hard some oversight may help to see which are the features that could be more relevant to support... I'm at least thinking to transactions.
Ahh but it can. Remember that even the dolphin has stored procedures.
Joshua D. Drake
MySQL 5 is slated as a requirement for Drupal 7, so stored procedures will be available... IF we can confirm that we have the necessary permissions to create them on a typical shared host. SQL Views I don't think we can use due to needing additional server-level permissions to create them in the first place, but I haven't investigated it in detail. Stored procedures may or may not have a similar issue; I really don't know yet. At the moment I am not dealing with stored procedures for the D7 database API. It's big enough as is. :-) Once it lands, we can think about it then. The main reason we have so many queries, though, is flexibility. Right now Drupal has "dumb modularity"; we call hooks and let them do "whatever", which usually involves queries. To further optimize our SQL would require either smarter query preparation across hooks or some sort of super-dynamic prepared statement that gets setup by hooks instead. Neither is a trivial task. For example, we call path lookup once for each l() function. That can easily eat up 100 queries right there. If we knew which ones we'd need, a single query that builds a targeted lookup table would be enormously faster... if we knew which ones we'd need in advance, which we don't. chx and I were discussing a possible learning/caching algorithm back in February, but I don't know that either of us will have time to do more than discuss due to being busy with other code (testing and databases, respectively, plus the registry). --Larry Garfield
On Wed, 30 Apr 2008 13:18:19 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
My queries, according to dev module, are quite rarely more than 5 ms. I don't know where you're getting that 30 ms number from. And,
Have you timed from execution on remote machine to connection on postgresql machine (pooled/persistent or not) and back? Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
You really have to look into devel.module as Larry suggested. It starts a timer before the query initiates and stops after it completes so it is certainly round trip. Your strong assertions are not based in facts. There is no way to shave off 5 seconds because drupal pages don't take that long unless you are doing extremely non standard stuff. On Wed, Apr 30, 2008 at 2:27 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
On Wed, 30 Apr 2008 13:18:19 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
My queries, according to dev module, are quite rarely more than 5 ms. I don't know where you're getting that 30 ms number from. And,
Have you timed from execution on remote machine to connection on postgresql machine (pooled/persistent or not) and back?
Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
Moshe Weitzman wrote:
You really have to look into devel.module as Larry suggested. It starts a timer before the query initiates and stops after it completes so it is certainly round trip. Your strong assertions are not based in facts. There is no way to shave off 5 seconds because drupal pages don't take that long unless you are doing extremely non standard stuff.
*sigh* I am done here. Thanks guys! Joshua D. Drake
On Wed, Apr 30, 2008 at 5:52 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
Moshe Weitzman wrote:
You really have to look into devel.module as Larry suggested. It starts a timer before the query initiates and stops after it completes so it is certainly round trip. Your strong assertions are not based in facts. There is no way to shave off 5 seconds because drupal pages don't take that long unless you are doing extremely non standard stuff.
*sigh*
I am done here. Thanks guys!
Joshua D. Drake
Joshua I am not sure why you are "done here". Typical page loads for a Drupal site should be under 800 ms or so. Ideally, they would be from 200 ms to 500 ms. That includes database time and page generation time as well. If you measure database time using the devel module in Drupal (as has been pointed to you earlier), you will see that 200 queries will take a 100 to 300 ms out of the 500 ms or so total page time. So your math is flawed (200 queries * 30 ms each = 5000 ms) and is not a common case at all. Perhaps to a specific application that you have, using PostgreSQL remotely, or some other special case. I can certainly say that the vast majority of Drupal sites on MySQL enjoy a page execution time of 800 ms or less, and well tuned sites are in the 200 - 300 ms range. If page loads for Drupal or any other web application is in the 5000 ms range, no one would be using it at all. -- Khalid M. Baheyeldin 2bits.com, Inc. http://2bits.com Drupal optimization, development, customization and consulting.
On Wed, 30 Apr 2008 11:27:31 -0700, "Joshua D. Drake" <jd@commandprompt.com> wrote:
On Wed, 30 Apr 2008 13:18:19 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
My queries, according to dev module, are quite rarely more than 5 ms. I don't know where you're getting that 30 ms number from. And,
Have you timed from execution on remote machine to connection on postgresql machine (pooled/persistent or not) and back?
Joshua D. Drake
No, I can't say I have because A) I don't use PostgreSQL and B) A database server that is sufficiently "remote" that network latency becomes a problem is too far away to begin with. It should be on a computer sitting on the same ethernet switch as the web server, ideally, or at the very least the same subnet in a data center. (Most worthwhile web hosts will do the latter, with really really fast ethernet connections between them). Also, don't use persistent connections with Drupal, or with PHP for that matter. They are frequently buggy. I'm not saying the DB layer can't be improved, it most certainly can, but I think you're looking in the wrong place to do so. --Larry Garfield
Quoting Larry Garfield <larry@garfieldtech.com>:
On Wed, 30 Apr 2008 11:27:31 -0700, "Joshua D. Drake" <jd@commandprompt.com> wrote:
On Wed, 30 Apr 2008 13:18:19 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
My queries, according to dev module, are quite rarely more than 5 ms. I don't know where you're getting that 30 ms number from. And,
Have you timed from execution on remote machine to connection on postgresql machine (pooled/persistent or not) and back?
Joshua D. Drake
No, I can't say I have because A) I don't use PostgreSQL and B) A database server that is sufficiently "remote" that network latency becomes a problem is too far away to begin with. It should be on a computer sitting on the same ethernet switch as the web server, ideally, or at the very least the same subnet in a data center. (Most worthwhile web hosts will do the latter, with really really fast ethernet connections between them).
Larry, your statement leads me to believe that you have no experience with large corporations where data latency can be more that 100 ms depending on where the data comes from. Your ideal situation doesn't fit a corporation with numerous databases in various cities spread throughout the country and world. All of the DB developers I know always use a stored procedure to gather the data to send back to the client because it is always faster to do so. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie- (I work for one of those corporations.) But that 100 ms latency would only affect non-Drupal data being pulled into the application -- say an inventory database housed in Connecticut with a web app server in Georgia (actual example). Even with such far-flung enterprises, we don't put the _Drupal_ database server that far away from a web server. To do so is to invite problems. And that kind of latency for external data needs to be either cached or (as suggested) stored. There are all kinds of ways to do this in Drupal -- as Matt, Neil and I discussed at DrupalCON Boston. I suppose I can imagine an enterprise that forces database storage to be in a separate unit from web servers, but that seems like a legacy technology mistake -- an artifact from an old IT worldview. Our NOC would never dream of putting the Drupal database on a separate switch from the web/app server. In our structure, the only real use I can see that would cause this latency is remote authentication against LDAP -- which, by design, is stored in a separate infrastructure from our web hosting -- but there isn't anything that Drupal can do about that kind of latency. I suspect that the folks on this thread are talking about different things. Which leads to much confusion and doesn't help anyone. Now, can Drupal learn from and exploit the value of stored procedures -- possibly, given the requirement restrictions that Larry mentions. In fact, we need people with such experience to be active developers on the project. -- Ken Rickard agentrickard@gmail.com http://ken.therickards.com On Thu, May 1, 2008 at 8:08 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Larry Garfield <larry@garfieldtech.com>:
On Wed, 30 Apr 2008 11:27:31 -0700, "Joshua D. Drake" < jd@commandprompt.com> wrote:
On Wed, 30 Apr 2008 13:18:19 -0500 Larry Garfield <larry@garfieldtech.com> wrote:
My queries, according to dev module, are quite rarely more than 5
ms. I don't know where you're getting that 30 ms number from. And,
Have you timed from execution on remote machine to connection on postgresql machine (pooled/persistent or not) and back?
Joshua D. Drake
No, I can't say I have because A) I don't use PostgreSQL and B) A database server that is sufficiently "remote" that network latency becomes a problem is too far away to begin with. It should be on a computer sitting on the same ethernet switch as the web server, ideally, or at the very least the same subnet in a data center. (Most worthwhile web hosts will do the latter, with really really fast ethernet connections between them).
Larry, your statement leads me to believe that you have no experience with large corporations where data latency can be more that 100 ms depending on where the data comes from. Your ideal situation doesn't fit a corporation with numerous databases in various cities spread throughout the country and world. All of the DB developers I know always use a stored procedure to gather the data to send back to the client because it is always faster to do so.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
On Thu, 1 May 2008 09:24:44 -0400 "Ken Rickard" <agentrickard@gmail.com> wrote:
Now, can Drupal learn from and exploit the value of stored procedures -- possibly, given the requirement restrictions that Larry mentions. In fact, we need people with such experience to be active developers on the project.
In my humble experience it would be hard to write an abstraction layer that let you write stored procedures across several DB. Joshua mentioned Catalyst. I don't know what does he meant when he wrote it can manage stored procedures. The best I can think is it offer standard methods to wrap stored procedures and then you'd have to write custom one for every DB you support. Not all stored procedures are functions and not all return records. I don't know if all the DB Drupal is planning to support provide DB functions that return records but if they do... it could be reasonable to write custom db functions that return the most important objects in Drupal, so people will be able to write SQL similarly to select one.a,two.b,two.c from someobject(id) as one join othertable as two on one.id=two.id But this really doesn't look to belong to the DB abstraction layer and if you put it in the object layer you risk to make it dependent on the DB you chose that is not a good help to isolate the DB layer and make it's API DB agnostic. One thing I've to fight with when I've to code sp is that db_query prepare and execute the query. I'd prefer this functions to be separated for debug purposes. It seems that D7 is going to support prepared statements but splitting "prepare" and "execute" in db_query would have been nice even before. Then to avoid a lot of boilerplate code you could wrap prepare and execute again in db_query but people could use the "prepare" (or cast and escape) part for their purpose independently. I think the path that compete the DB layer would be to let developer provide easier different functions for different DB without resorting to checking db_type. Stored procedures are great for encapsulation, coherency, transaction management, access control... but I think it is hard to offer a flexible framework for dev that is based on sp and I don't think they are suited for Drupal audience. I use stored procedures with Drupal. I think there is nothing missing in Drupal that could help to use stored procedures across several DB. You write different versions of your stored procedures in .install, wrap them in functions, put them in different files that are loaded according to which DB you're using and you're done. The largest portion of the job is to write different versions of sp for different DB, there is no shortcut. Support for transaction may be easier, provide a more agnostic API and be quite useful, I'd say there are several part of core where transaction could be used proficiently to make the overall more solid. Something that would be harder to plan would be to make transactions extend across hooks. eg. it would be nice to make the overall process of creating/updating a user transactional so that if a contrib module add proprieties to a user the user never get half created. I don't think that db that don't support transactionq will suffer from supporting transactions at this level, they just won't offer that level of coherency. -- Ivan Sergio Borgonovo http://www.webthatworks.it
Quoting Ken Rickard <agentrickard@gmail.com>:
Earnie-
(I work for one of those corporations.)
But that 100 ms latency would only affect non-Drupal data being pulled into the application -- say an inventory database housed in Connecticut with a web app server in Georgia (actual example).
I would give away too much to explain in detail but we store 100K rows of usage data in any given minute. The account holders can review those rows real time including months of history. The set of data is too large and too sensitive to store on the web server. Just one example. Lots of data everywhere. I can't think that any of our data is actually sitting on the web servers except for internal use sites. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie- I did not say that we store data on the web server -- in fact, we always keep the two separate. I simply said that we place the datadase server on the same network switch (in reality, on the same rack) as the web server, to avoid latency issues. We actually use a load-balanced web server connected to replicated MySQL. - Ken On Fri, May 2, 2008 at 9:13 AM, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Ken Rickard <agentrickard@gmail.com>:
Earnie-
(I work for one of those corporations.)
But that 100 ms latency would only affect non-Drupal data being pulled into the application -- say an inventory database housed in Connecticut with a web app server in Georgia (actual example).
I would give away too much to explain in detail but we store 100K rows of usage data in any given minute. The account holders can review those rows real time including months of history. The set of data is too large and too sensitive to store on the web server. Just one example. Lots of data everywhere. I can't think that any of our data is actually sitting on the web servers except for internal use sites.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- Ken Rickard agentrickard@gmail.com http://ken.therickards.com
Prepared Statements effectively achieve the CPU (thus latency) performance improvements of Stored Procedures and do so in a more platform independent way than Stored Procedures. If you use the most obvious DB optimizations (connection pooling + prepared statements) then you are doing very well. If that performance is not sufficient and you are waiting for reads, then use caching. The bottleneck for databases will almost always occur at Disk I/O. The strongest argument I've heard for stored procedures is that they provide an API. So if I have 5 different applications using a database, and I don't want to rewrite the same logic for each app, perhaps stored procedures make sense. I would still try to avoid them because they tie all of my applications to DBMS specific layer. If the application is for Oracle or Microsoft, they probably don't care too much about the DBMS dependency. -Dave
Joshua D. Drake wrote:
I admit that I tend to stay on the database side of things and a lot of what I do is fix deficiencies in the Drupal model by moving them properly into the database and having Drupal called stored procedures etc.. but I can say that the customers that we deal with are sticking with 5 precisely because of the concerns on this thread.
That's great! You do work on Drupal that could benefit the entire community, and you don't contribute it back. Yet you want us to make changes that will benefit you.
On Wed, 30 Apr 2008 10:16:42 -0700 Earl Miles <merlin@logrus.com> wrote:
Joshua D. Drake wrote:
I admit that I tend to stay on the database side of things and a lot of what I do is fix deficiencies in the Drupal model by moving them properly into the database and having Drupal called stored procedures etc.. but I can say that the customers that we deal with are sticking with 5 precisely because of the concerns on this thread.
That's great! You do work on Drupal that could benefit the entire community, and you don't contribute it back. Yet you want us to make changes that will benefit you.
Actually this is false. And before you go flaming off into the wilderness, you should consider you have zero basis to make the statement. You have no idea who I am or what I have been doing. Nor do you have any idea (obviously otherwise you wouldn't have made the statement) of how much we give back to the community. Sincerely, Joshua D. Drake -- The PostgreSQL Company since 1997: http://www.commandprompt.com/ PostgreSQL Community Conference: http://www.postgresqlconference.org/ United States PostgreSQL Association: http://www.postgresql.us/ Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Joshua D. Drake schrieb:
etc.. but I can say that the customers that we deal with are sticking with 5 precisely because of the concerns on this thread.
Realistically, nobody having a working D5 site and not planning a major overhaul will not update to D6 completely regardless of whether views/cck/panels/holy_grail for D6 is available or not. The question is whether new projects would use D5 or D6. Today, I advised somebody to go with D5. This was mainly because of the tight deadline (end of may). If he had said "end of June" I might have considered to go with D6 (D5 would still be safer). "end of July" would be a definite yes for D6. This would be about half half a year after D6 initially got released, that's not too bad. D6.0 was quite unusable for larger sites anyway due to some bugs relevant for performance. Cheers, Gerhard -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIGKtdfg6TFvELooQRAtp5AJ9gL/o29RyCwqnIpBBXW5JkQWcddgCfR9VB 8q5HQWPLE2dFMYq++kIHlQ0= =O6ED -----END PGP SIGNATURE-----
participants (13)
-
Caleb Gilbert -
Daniel F. Kudwien -
David Durham, Jr. -
Earl Miles -
Earnie Boyd -
Gerhard Killesreiter -
Ivan Sergio Borgonovo -
Joshua D. Drake -
Ken Rickard -
Khalid Baheyeldin -
Larry Garfield -
Moshe Weitzman -
Robert Douglass