On Tuesday 15 April 2008 18:22, Tom Jackson wrote:
I'll try to combine Daniel's code with my filter to turn on the switch for
ns_return.
I have a test release of the nszlib module, which handles ADP compression, and
static files (taken from Daniel's example filters), plus dynamic data
I don't know where it's documented, but that's been the behavior for a
long time; we've relied on it since 3.4.2, and I think Alex Hisen showed
me it working in 2.0. I wanted to remember reading it in the Tcl
modules section or the server startup section of the old 3.0 manual
that's still @
I think the ns_odbc driver can survive from one connection to another. When I
use it, I have to put in a trace filter to close/return the handle.
I can't imagine that it is a good idea to just randomly reuse an open handle.
You risk running out of handles for one, but the state of the
Hi,
Brent Welch wrote some ns_share code which worked with Tcl variable
traces to emulate the original code. It works except for a few edge
cases but is generally considered less efficient and flexible than the
new nsv_* commands. So, when I say we gave up on ns_share I mean we
There is also the Ns_Task API which is more flushed out, and is used by the
new ns_http command.
But each Ns_Task implementation requires coding in C, which is probably okay
for those needing high performance.
It is still difficult to figure out exactly how it should be used. Anyway, for
You should look at the pg driver, I think it can emulate bind variables, or
maybe it is part of the db_* API of OpenACS.
I also have a wrapper API for ns_db which has more of a stored procedure type
API.
Here is a link to an example application:
On Apr 16, 2008, at 2:33 PM, Tom Jackson wrote:
You should look at the pg driver, I think it can emulate bind
variables, or
maybe it is part of the db_* API of OpenACS.
You have to compile nspostgres.c for OpenACS use to make the command
available.
Then use ns_pg_bind rather than
On 2008.04.16, Jay Rohr [EMAIL PROTECTED] wrote:
I am using the tsv (from the thread package) functions within aolserver
and, at least for my uses, it is faster than the nsv equivalents. [...]
Can we please see the benchmarks (code and results) you used to
demonstrate this?
--
Dossy
On Wednesday 16 April 2008 15:11, Don Baccus wrote:
On Apr 16, 2008, at 2:33 PM, Tom Jackson wrote:
You should look at the pg driver, I think it can emulate bind
variables, or
maybe it is part of the db_* API of OpenACS.
You have to compile nspostgres.c for OpenACS use to make the command
On Apr 16, 2008, at 3:44 PM, Dossy Shiobara wrote:
I have wanted to add bind variable support to nsdb for a _long_ time,
but never got around to computing this support matrix that I describe
above.
If you do, it needs to be a config option, because with Oracle you do
*not* want to do this
On 17/04/2008, at 8:14 AM, Dossy Shiobara wrote:
I have wanted to add bind variable support to nsdb for a _long_ time,
but never got around to computing this support matrix that I describe
above.
I don't really like bind variables, I would much rather see it
implemented like:
ns_db select
On Apr 16, 2008, at 4:20 PM, Bas Scheffers wrote:
On 17/04/2008, at 8:14 AM, Dossy Shiobara wrote:
I have wanted to add bind variable support to nsdb for a _long_ time,
but never got around to computing this support matrix that I describe
above.
I don't really like bind variables, I would much
On Wednesday 16 April 2008 16:20, Bas Scheffers wrote:
I don't really like bind variables, I would much rather see it
implemented like:
ns_db select $db select * from people where country = $1 and age
$2 [list au 25]
You can look at the examples in my recent post. It works with plain 'ol
On Thu, Apr 17, 2008 at 08:50:46AM +0930, Bas Scheffers wrote:
Subject: Re: [AOLSERVER] aolserver and Pgtcl
I don't really like bind variables, I would much rather see it
implemented like:
There are other people who prefer different styles of
bind-variable-like support too, notably D.
On 17/04/2008, at 9:25 AM, Tom Jackson wrote:
Your script/page level code can remain unchanged even when you switch
databases.
That looks more like an OR mapping framework. I think that is a good
thing to have also but to me it is separate from having bind variables
in the core nsdb api. I
On Wednesday 16 April 2008 17:06, Andrew Piskorski wrote:
As a design principle, remember that ns_db itself never cares what is
in the query at all! ns_db doesn't even care whether the query is
SQL or something else, the query is just some opaque string which gets
passed allong to the proper
+1
- Original Message
From: Dossy Shiobara [EMAIL PROTECTED]
To: AOLSERVER@LISTSERV.AOL.COM
Sent: Wednesday, April 16, 2008 7:00:14 PM
Subject: Re: [AOLSERVER] ns_db and bind variable support
On 2008.04.17, Bas Scheffers [EMAIL PROTECTED] wrote:
That brings me to another subject: do we
This is how pgtcl actually does bind variables...
- Original Message
From: Bas Scheffers [EMAIL PROTECTED]
To: AOLSERVER@LISTSERV.AOL.COM
Sent: Wednesday, April 16, 2008 4:20:46 PM
Subject: Re: [AOLSERVER] aolserver and Pgtcl
On 17/04/2008, at 8:14 AM, Dossy Shiobara wrote:
I have
The other is performance.
Jade
On Wed, Apr 16, 2008 at 5:40 PM, Bas Scheffers [EMAIL PROTECTED] wrote:
I would never say that; not having to worry about quoting is one of the
main advantages of using bind variables/parameters.
Bas.
--
AOLserver - http://www.aolserver.com/
To Remove
On 2008.04.16, Jade Rubick [EMAIL PROTECTED] wrote:
Can someone explain why we need prepared statements? I thought by
using bind variables, we avoid the SQL parse time (at least with
Oracle, that's my understanding) if you're using the same SQL but with
different values in your bind variables.
On Wed, Apr 16, 2008 at 5:20 PM, Bas Scheffers [EMAIL PROTECTED] wrote:
On 17/04/2008, at 8:14 AM, Dossy Shiobara wrote:
I don't really like bind variables, I would much rather see it implemented
like:
ns_db select $db select * from people where country = $1 and age $2
[list au 25]
You
On Apr 16, 2008, at 8:48 PM, Jeff Rogers wrote:
I've been told this by every oracle dba I've worked with and the
performance gains I've seen by moving to prepared statements is
generally quite small unless the sql is horrendously complex, and
even then the backends appear to do caching of
On 2008.04.16, Don Baccus [EMAIL PROTECTED] wrote:
Did you try speeding up the plan generation using Oracle's method of
giving hints?
Yes, we /*+HINTED*/. Oracle trace log showed parse times of 160ms +/-
10ms. Plan generation wasn't the killer. Parsing the SQL was the
killer. It wasn't
I haven't seen any discussion here which approximates how current SQL
standards handle prepared statements. Actual prepared statements would be of
little benefit in AOLserver since the lifetime of an SQL session is so short,
there is very little opportunity for reuse. Prepared statements are
On 2008.04.16, Tom Jackson [EMAIL PROTECTED] wrote:
Actual prepared statements would be of little benefit in AOLserver
since the lifetime of an SQL session is so short, [...]
Huh? AOLserver offers pooled, persistent database connections.
--
Dossy Shiobara | [EMAIL PROTECTED] |
25 matches
Mail list logo
