Hmmm,

I would beg to differ.... The thing about JDBC drivers which
Coldfusion usesm all use pooling. So the question is this, they would
need to know when not to pool the query and when to pool the query.

That makes me think that the language that Coldfusion is needs to be
more typecast, I know you have heard me rant about that in the past.

But look at this way, we can create CFC's an when in development they
are typecast. In other words if we tell the cfc we want a numeric, the
cfc will expect a numeric. But when we move to production and unless
you have control over the CFIDE/ADMINISTRATOR you may find that
everything is passed as any for performance.

Why bother, whe give the left hand one thing and then the right hand
another. This is no differento the JDBC drivers for the database. Why
should Coldfusion be smart and be definitive when it comes ot pooling,
and why it doesn't just do it.

I guess we live in a world of backwards compatability, but how is
allowing the any in a CFC in production backwards compatible?

I look at the future and I talk in that manner, and small band aid
solutions like cfqueryparam is as far as I am concerned a bandaid
solution to a much bigger problem.

My 3c :-)


On 3/15/08, Zac Spitzer <[EMAIL PROTECTED]> wrote:
>
> it's like the difference between an app written using cfc's and a very
> old school cfm procedural app
>
> with bound sql it's re-usable,  with unbound sql it isn't so eaily re-usable
>
> On Sat, Mar 15, 2008 at 5:02 PM, CyberAngel <[EMAIL PROTECTED]> wrote:
> >
> >  No kidding Steve.
> >
> >  I am looking at why the pooling wasn't made permanent, and had to be
> >  switched on by using cfqueryparam?
> >
> >
> >
> >
> >
> >
> >
> >  -----Original Message-----
> >  From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf
> >  Of Steve Onnis
> >
> >
> > Sent: Saturday, 15 March 2008 4:59 PM
> >  To: cfaussie@googlegroups.com
> >  Subject: [cfaussie] Re: programmer etiquette and writing good CF code
> >
> >
> >  Its not all about pooling. That's just one of the advantages for using it
> >
> >  -----Original Message-----
> >  From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf
> >  Of CyberAngel
> >  Sent: Saturday, 15 March 2008 4:56 PM
> >  To: cfaussie@googlegroups.com
> >  Subject: [cfaussie] Re: programmer etiquette and writing good CF code
> >
> >
> >  I was refering to my statement. Coldfusion should just take the query build
> >  and pool it, without the need of cfqueryparam. Like whitespace management,
> >  it should just happen, and not have an option in the admin section.
> >
> >
> >
> >
> >
> >  -----Original Message-----
> >  From: cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf
> >  Of Zac Spitzer
> >  Sent: Saturday, 15 March 2008 4:47 PM
> >  To: cfaussie@googlegroups.com
> >  Subject: [cfaussie] Re: programmer etiquette and writing good CF code
> >
> >
> >  talking in terms of oracle
> >
> >  select  this,that
> >  where   thisid = #thisid#
> >                 and thatid =#thatid#
> >
> >  isn't pooled
> >
> >  select  this,that
> >  where   thisid = <CFQUERYPARAM VALUE="##thisid##"
> >  CFSQLType="CF_SQL_INTEGER">
> >                 and thatid =#thatid#
> >
> >  would be pooled once for each different thatid passed in
> >
> >  select  this,that, '#user_id' user_id
> >  where   thisid = <CFQUERYPARAM VALUE="##thisid##"
> >  CFSQLType="CF_SQL_INTEGER">
> >                 and thatid =#thatid#
> >
> >  would be pooled once for each different thatid & userid combination passed
> >  in
> >
> >
> >
> >  On Sat, Mar 15, 2008 at 4:36 PM, Andrew Scott <[EMAIL PROTECTED]>
> >  wrote:
> >  >
> >  >  Zac, are you saying that
> >  >
> >  >  select this,that
> >  >  where
> >  >  thisid = #thisid# and thatid =#thatid#
> >  >
> >  >  is pooled?
> >  >
> >  >
> >  >
> >  >
> >  >
> >  >  On 3/15/08, Zac Spitzer <[EMAIL PROTECTED]> wrote:
> >  >  >
> >  >  > With oracle CFQUERYPARAM creates a cursor, which is a limited
> >  > resource  > db side, if your going  > to use  CFQUERYPARAM with oracle
> >  > it's a all or nothing situation as  > having one un-bound changing  >
> >  > value in the query will create a separate cursor for each which is bad
> >  news...
> >  >  >
> >  >  > it gets interesting at time's tho.... sometimes when performance  >
> >  > tuning, it's better to not bind...
> >  >  > see the end of this article
> >  >  >
> >  > http://www.oracle.com/technology/oramag/oracle/08-jan/o18asktom.html
> >  >  >
> >  >  > On Sat, Mar 15, 2008 at 3:57 PM, CyberAngel <[EMAIL PROTECTED]> wrote:
> >  >  > > I was thinking about this the last few days.
> >  >  > >
> >  >  > > <cfquery> should not need to be told by cfqueryparam to do
> >  > prepared  > > statement pooling.
> >  >  >
> >  >  > It does doesn't it? just depends on the db  >  > >  > >  > >  > >
> >  > It should just happen.
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > > From: cfaussie@googlegroups.com
> >  > [mailto:[EMAIL PROTECTED] On
> >  Behalf
> >  >  > > Of Simon Haddon
> >  >  > >  Sent: Saturday, 15 March 2008 1:35 PM  > >  > >  > >  To:
> >  > cfaussie@googlegroups.com  > >  Subject: [cfaussie] Re: programmer
> >  > etiquette and writing good CF
> >  code
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > > Itend to agree that cfqueryparam is NOT always warranted.
> >  > Sometimes
> >  you
> >  >  > > have values which are hard coded (rare but true), sometimes
> >  > values
> >  are
> >  >  > > internally checked before the the query is built, sometimes the
> >  > SQL
> >  is built
> >  >  > > prior to the cfquery.
> >  >  > >
> >  >  > >  I am sure there are lots of reasons not to. There are also lots
> >  > of
> >  reasons
> >  >  > > to use cfqueryparam.  It really depends in the situation.  It
> >  > also
> >  depends
> >  >  > > on the coding standards.
> >  >  > >
> >  >  > >
> >  >  > > On 14/03/2008, CyberAngel <[EMAIL PROTECTED]> wrote:
> >  >  > >
> >  >  > >
> >  >  > >  Steve...
> >  >  > >
> >  >  > >  That is the reason why I tend not to use them, mainly because
> >  > all my
> >  code
> >  >  > > is
> >  >  > >  validated well before it even hit a cfc to do any DAO's.
> >  >  > >
> >  >  > >  It might be best practice, but it is not always applicable:-)  >
> >  > >  > >  > >  > >  > >  > >  -----Original Message-----  > >  From:
> >  > cfaussie@googlegroups.com [mailto:[EMAIL PROTECTED]
> >  On
> >  >  > > Behalf
> >  >  > >
> >  >  > >  Of Steve Onnis
> >  >  > >  Sent: Friday, 14 March 2008 2:39 PM  > >  To:
> >  > cfaussie@googlegroups.com  > >  Subject: [cfaussie] Re: programmer
> >  > etiquette and writing good CF
> >  code
> >  >  > >
> >  >  > >
> >  >  > >  Not only that.  It performs validation tasks and properly
> >  > escapes
> >  texts
> >  >  > >  string in both complex variables like arrays and structure
> >  > values
> >  and
> >  >  > > simple
> >  >  > >  values.
> >  >  > >
> >  >  > >  I guess its called "Best Practise" for a reason hey?
> >  >  > >
> >  >  > >  -----Original Message-----
> >  >  > >  From: cfaussie@googlegroups.com
> >  > [mailto:[EMAIL PROTECTED]
> >  On
> >  >  > > Behalf
> >  >  > >  Of CyberAngel
> >  >  > >  Sent: Friday, 14 March 2008 2:37 PM  > >  To:
> >  > cfaussie@googlegroups.com  > >  Subject: [cfaussie] Re: programmer
> >  > etiquette and writing good CF
> >  code
> >  >  > >
> >  >  > >
> >  >  > >  Yes but is not supported by all databases:-)  > >  > >  Unless
> >  > that has changed recently.
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >  -----Original Message-----
> >  >  > >  From: cfaussie@googlegroups.com
> >  > [mailto:[EMAIL PROTECTED]
> >  On
> >  >  > > Behalf
> >  >  > >  Of Mark Mandel
> >  >  > >  Sent: Friday, 14 March 2008 2:35 PM  > >  To:
> >  > cfaussie@googlegroups.com  > >  Subject: [cfaussie] Re: programmer
> >  > etiquette and writing good CF
> >  code
> >  >  > >
> >  >  > >
> >  >  > >  PreparedStatement pooling is always a good thing performance wise.
> >  >  > >
> >  >  > >  Mark
> >  >  > >
> >  >  > >  On Fri, Mar 14, 2008 at 2:29 PM, CyberAngel <[EMAIL PROTECTED]>
> >  wrote:
> >  >  > >  >
> >  >  > >  >  Mark,
> >  >  > >  >
> >  >  > >  >  What are the 2 main reasons for using cfqueryparam, and you
> >  > know
> >  that
> >  >  > >  > one
> >  >  > >  of
> >  >  > >  >  those points is not supported by all databases?
> >  >  > >  >
> >  >  > >  >
> >  >  > >  >
> >  >  > >  >
> >  >  > >  >  -----Original Message-----
> >  >  > >  >  From: cfaussie@googlegroups.com
> >  [mailto:[EMAIL PROTECTED] On
> >  >  > >  Behalf
> >  >  > >  >
> >  >  > >  > Of Mark Mandel
> >  >  > >  >  Sent: Friday, 14 March 2008 2:20 PM  > >  >  To:
> >  > cfaussie@googlegroups.com  > >  >  > >  >  > >  > Subject: [cfaussie]
> >  > Re: programmer etiquette and writing good CF
> >  code
> >  >  > >  >
> >  >  > >  >
> >  >  > >  >  When is there no point?
> >  >  > >  >
> >  >  > >  >  * Befuddled face *
> >  >  > >  >
> >  >  > >  >  Mark
> >  >  > >  >
> >  >  > >  >  On Fri, Mar 14, 2008 at 2:18 PM, CyberAngel
> >  > <[EMAIL PROTECTED]>
> >  wrote:
> >  >  > >  >  >
> >  >  > >  >  >  LOL.
> >  >  > >  >  >
> >  >  > >  >  >  We all get there. And the thing I will ask, did you
> >  > inherit
> >  this
> >  >  > >  > or is
> >  >  > >  it
> >  >  > >  >  >  someone in your organisation?
> >  >  > >  >  >
> >  >  > >  >  >  I don't use cfqueryparam, when I know there is no point to
> >  > use
> >  it.
> >  >  > >  > But
> >  >  > >  I
> >  >  > >  >  >  know when too, and when not too. As for scoping variables,
> >  that is
> >  >  > >  just
> >  >  > >  >  >  purely bad habit.
> >  >  > >  >  >
> >  >  > >  >  >
> >  >  > >  >  >
> >  >  > >  >  >
> >  >  > >  >  >  -----Original Message-----  > >  >  >  From:
> >  > cfaussie@googlegroups.com
> >  [mailto:[EMAIL PROTECTED]
> >  >  > >  > On  Behalf  >  Of barry.b  >  Sent: Friday, 14 March 2008 1:59
> >  > PM
> >  >
> >  >  > >  > To: cfaussie  >  Subject: [cfaussie] programmer etiquette and
> >  writing
> >  >  > >  > good CF code  >  >  >  >  > (I thought the teacher in me was
> >  > well
> >  and
> >  >  > >  > truly burnt to a crisp...
> >  >  > >  >  >  aparently not...)
> >  >  > >  >  >
> >  >  > >  >  >
> >  >  > >  >  >  hyperthetical
> >  >  > >  >  >
> >  >  > >  >  >  * you're finishing off someone elses project, it's only a
> >  couple
> >  >  > >  > of  >  weeks of work  >  * that person is someone that you
> >  know/see
> >  >  > >  > around the traps  >  * you know you're not the world's gift to
> >  coding
> >  >  > >  > but trying to follow  >  best practices has put you in good
> >  > stead
> >  for
> >  >  > >  > years (and reduced the  >  amount of obscure bugs)  >  * the
> >  > code
> >  is
> >  >  > >  > full of (lets say) less than optomial practices eg
> >  >  > >  >  >   - SELECT *
> >  >  > >  >  >   - reuse of the variable "ID" on the same page for diffent
> >  usages/
> >  >  > >  >  >  contexts
> >  >  > >  >  >   - hardly any use of scopes (esp URL and FORM) with lots of
> >  using
> >  >  > >  >  >  isDefined()
> >  >  > >  >  >   - not a cfqueryparam to be seen.
> >  >  > >  >  >
> >  >  > >  >  >  do you
> >  >  > >  >  >
> >  >  > >  >  >  a) shoot them when next you meet then dance on their grave.
> >  >  > >  >  >  b) make a semi formal list of what's wrong and why then
> >  > bail
> >  them
> >  >  > >  > up  >  to go on "chapter-and-verse" about it  >  c) make an
> >  informal
> >  >  > >  > comment on next meeting that it "had a few rough  >  edges"
> >  > and
> >  leave
> >  >  > >  > it at that  >  d) keep your mouth shut, your head down and
> >  > keep
> >  saying
> >  >  > >  > to yourself  >  "it's only for a short while"...
> >  >  > >  >  >
> >  >  > >  >  >  thoughts?
> >  >  > >  >  >
> >  >  > >  >  >
> >  >  > >  >  >
> >  >  > >  >  >
> >  >  > >  >  >  >
> >  >  > >  >  >
> >  >  > >  >
> >  >  > >  >
> >  >  > >  >
> >  >  > >  >  --
> >  >  > >  >
> >  >  > >  > E: [EMAIL PROTECTED]
> >  >  > >  >  W: www.compoundtheory.com
> >  >  > >  >
> >  >  > >  >
> >  >  > >  >
> >  >  > >  >
> >  >  > >  >
> >  >  > >  > >
> >  >  > >  >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >  --
> >  >  > >  E: [EMAIL PROTECTED]
> >  >  > >  W: www.compoundtheory.com
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >
> >  >  > >  >
> >  >  > >
> >  >  >
> >  >  >
> >  >  >
> >  >  > --
> >  >
> >  > > Zac Spitzer -
> >  >  > http://zacster.blogspot.com (My Blog)  > +61 405 847 168  >  > >  >
> >  >
> >  >
> >  >  --
> >  >
> >  >
> >  >
> >  >  Senior Coldfusion Developer
> >  >  Aegeon Pty. Ltd.
> >  >  www.aegeon.com.au
> >  >  Phone: +613  8676 4223
> >  >  Mobile: 0404 998 273
> >  >
> >  >
> >  >
> >  >  >
> >  >
> >
> >
> >
> >  --
> >  Zac Spitzer -
> >  http://zacster.blogspot.com (My Blog)
> >  +61 405 847 168
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >  >
> >
>
>
>
> --
> Zac Spitzer -
> http://zacster.blogspot.com (My Blog)
> +61 405 847 168
>
> >
>


-- 



Senior Coldfusion Developer
Aegeon Pty. Ltd.
www.aegeon.com.au
Phone: +613  8676 4223
Mobile: 0404 998 273

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"cfaussie" group.
To post to this group, send email to cfaussie@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/cfaussie?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to