RE: [ACFUG Discuss] List Handling

2011-11-04 Thread Matthew Nicholson
Afternoon All!

 

It looks as though scoping the variable may have done it although I'll
be frank, I'm not quite sure why. 

 

I also found the issue related to comparing ListFindNoCase() and
ListContainsNoCase(). While I done it previously without scoping the
variable with no success, once scoped, ListContainsNoCase() returned
something other than 1.

 

I'm not sure of the underlying reason for this issue as it was
functioning perfectly up till about a week ago (according to the
client).

 

As time allows, I'll throw together a few tests locally and see if I
can't pinpoint where the functions are breaking down.

 

Thank you all very much for your direction!

 

Matthew R. Nicholson

SolTech, Inc.

www.soltech.net http://www.soltech.net/ 

(p) 404.601.6000, Ext 233

(c) 770.833.5326

Yes.  We can get you there. 

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Cameron
Childress
Sent: Wednesday, November 02, 2011 6:00 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] List Handling

 

First this I see is to try scoping your id var:

 

CFSET pos = ListFindNoCase(autoOrders, qryAuto.id) 

 

If the value of id is remaining the same as the first query value,
then it's always going to return 1 as the list position. 

 

You can also output the id value and it's list pos as a debug measure
if you want...  Either inline or using cflog or similar.  

 

cfoutput#id#:#pos#br//cfoutput

 

If that doesn't uncover your problem, shoot back an email.

 

-Cameron

 

On Wed, Nov 2, 2011 at 5:23 PM, Matthew Nicholson
matthew.nichol...@soltech.net wrote:

I'm always happy to share an example of bad practices! :D

 

All things said and done this solution is far from ideal, which is an
understatement, but I'm always excited to hear options and opinions. 

 

From a high level, this is the current process outlined below in code:

1.   Stored Proc dbo.Orders provides data 

2.   QoQ qryAuto allows us to determine a subset of Orders that meet
specific criteria 

3.   Loop through the QoQ qryAuto to perform specific processes
against specific Orders

4.   If the order doesn't meet those requirements, we then modify
the list autoOrders

5.   Lastly, the autoOrders is used to limit what we display to the
User

 

cfstoredproc procedure=dbo.Orders datasource=#main_dsn#
returncode=yes

  cfprocresult name=Orders resultset=1 /

/cfstoredproc

 

cfquery name=qryAuto dbtype=query

  Select *

  From Orders

  Where Blah Blah Blah

/cfquery

 

CFIF qryAuto.recordCount GT 0

  CFSET autoOrders = ValueList(qryAuto.id, , )

CFELSE

  CFSET autoOrders = 0

/CFIF

 

CFLOOP QUERY=qryAuto

 

  CFIF Check1  Check2  Check3

Do all sorts of goodies

  CFELSE

CFSET pos = ListFindNoCase(autoOrders, id)

CFIF pos NEQ 0

  CFSET autoOrders = ListDeleteAt(autoOrders,pos)

/CFIF

  /CFIF

/CFLOOP

 

In the end, I was curious if I had just run headlong into an issue
because of the use of lists. I will say, the list autoOrders shouldn't
be long long ever as this process is supposed to kick-off
continuously. But, if this is the heart of the issue then a redesign is
obviously necessary.   

 

Thank you all again for your thoughts and insight!

 

Matthew R. Nicholson

SolTech, Inc.

www.soltech.net http://www.soltech.net/ 

(p) 404.601.6000, Ext 233 tel:404.601.6000%2C%20Ext%20233 

(c) 770.833.5326

Yes.  We can get you there. 

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Cameron
Childress
Sent: Wednesday, November 02, 2011 2:49 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] List Handling

 

First, as to your actual problem with listFindNoCase() returning 1, I'd
say show your code.  There could be a number of logic problems causing
this.

 

However, I think you are going to run into another problem first.
Because of the way CF handles lists, it's a real REAL bad idea to keep
long lists and loop over them or do other things to them in code.  The
longer a list gets the longer your loop is going to take - not
incrementally, closer to exponentially.

 

ColdFusion treats a list just like a string, and when you ask for item
300, it first has to look for the previous 299 items before it gets to
300. When you ask for item 301?  Yup, goes through all 300 again before
finally settling on item 301.  It's much MUCH better to use an array or
struct or any other sort of structured data.  A ColdFusion list is not
structured, it's just a real long string.

 

I've seen apps that take 60+ seconds to render a page that uses long
lists.  Once converted to arrays, that same page took 1 second to run.

 

Your situation might not be as dire, but the longer your list gets the
worse your potential performance problems are going to get.  Short lists
are fine, but I wouldn't want a 300+ item list floating around being
looped over.  In my previous example, the list was 4,000+ items long

Re: [ACFUG Discuss] List Handling

2011-11-03 Thread Ajas Mohammed
Mathew,

any update on this? Did you find solution? If not share a sample list and
we can give it a shot.

Ajas Mohammed /
http://ajashadi.blogspot.com
We cannot become what we need to be, remaining what we are.
No matter what, find a way. Because thats what winners do.
You can't improve what you don't measure.
Quality is never an accident; it is always the result of high intention,
sincere effort, intelligent direction and skillful execution; it represents
the wise choice of many alternatives.


On Wed, Nov 2, 2011 at 8:34 PM, Steve Ross nowhid...@gmail.com wrote:

 I am guessing whatever you are trying to do could be accomplished in sql
 in a much more elegant solution... might be wrong but, that would be worth
 investigating as well.


 On Wed, Nov 2, 2011 at 7:00 PM, Charlie Arehart char...@carehart.orgwrote:

 Consider also Matthew that it may be helpful to output the autoorders as
 well for debugging purposes. It, too, may not be what you expect.

 For instance, if this code is in a CFC method, then you could be having a
 situation where other requests are causing conflicts with the variables. If
 you’ve not heard of it as an option, I appreciate that it will sound
 far-fetched. Like Cam said, let us know what you think and we can proceed.
 

 ** **

 /charlie

 ** **

 *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Cameron
 Childress
 *Sent:* Wednesday, November 02, 2011 6:00 PM

 *To:* discussion@acfug.org
 *Subject:* Re: [ACFUG Discuss] List Handling

 ** **

 First this I see is to try scoping your id var:

 ** **

 CFSET pos = ListFindNoCase(autoOrders, qryAuto.id) 

 ** **

 If the value of id is remaining the same as the first query value, then
 it's always going to return 1 as the list position. 

 ** **

 You can also output the id value and it's list pos as a debug measure
 if you want...  Either inline or using cflog or similar.  

 ** **

 cfoutput#id#:#pos#br//cfoutput

 ** **

 If that doesn't uncover your problem, shoot back an email.

 ** **

 -Cameron

 ** **

 -
 To unsubscribe from this list, manage your profile @
 http://www.acfug.org?fa=login.edituserform

 For more info, see http://www.acfug.org/mailinglists
 Archive @ http://www.mail-archive.com/discussion%40acfug.org/
 List hosted by FusionLink http://www.fusionlink.com
 -




 --
 Steve Ross
 web application  interface developer
 http://blog.stevensross.com
 [mobile] (912) 344-8113
 [ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ]



Re: [ACFUG Discuss] List Handling

2011-11-02 Thread Cameron Childress
First, as to your actual problem with listFindNoCase() returning 1, I'd say
show your code.  There could be a number of logic problems causing this.

However, I think you are going to run into another problem first.  Because
of the way CF handles lists, it's a real REAL bad idea to keep long lists
and loop over them or do other things to them in code.  The longer a list
gets the longer your loop is going to take - not incrementally, closer to
exponentially.

ColdFusion treats a list just like a string, and when you ask for item 300,
it first has to look for the previous 299 items before it gets to 300. When
you ask for item 301?  Yup, goes through all 300 again before finally
settling on item 301.  It's much MUCH better to use an array or struct or
any other sort of structured data.  A ColdFusion list is not structured,
it's just a real long string.

I've seen apps that take 60+ seconds to render a page that uses long lists.
 Once converted to arrays, that same page took 1 second to run.

Your situation might not be as dire, but the longer your list gets the
worse your potential performance problems are going to get.  Short lists
are fine, but I wouldn't want a 300+ item list floating around being looped
over.  In my previous example, the list was 4,000+ items long.

Show your code or describe what you are trying to achieve and perhaps we
can collectively help you find a better way.

-Cameron

On Wed, Nov 2, 2011 at 2:35 PM, Matthew Nicholson 
matthew.nichol...@soltech.net wrote:

 Morning All!

 ** **

 I could swear we had a discussion about this awhile ago (although I may
 just be remembering an article from Charlie’s site).

 ** **

 I’m experiencing a bit of a  head scratcher in regards to lists and
 managing them. 

 **1.   **Using a QoQ, we create a ValueList from one of its columns***
 *

 **a.   **The ValueList is rather sizable list (400+ entries) of
 identifiers

 **2.   **We then iterate through the QoQ and do some logic

 **3.   **Should one of those entries (in the loop based upon the QoQ)
 not meet the criteria of the logic, we then remove it from the ValueList
 previously created ValueList

 ** **

 Now, previously, I’d simply search through the list using;

 ** **

 *ListFindNoCase()*

 ** **

 And then delete the entry in the ValueList that needed to be removed using
 *ListDeleteAt()*. 

 ** **

 However, the rub that I’m experiencing now is that *ListFindNoCase()*which 
 worked previously is now only returning 1 when the entry is found
 (even if it’s obviously not the first entry in the list).

 ** **

 Questions!

 **· **Have you all experienced similar problems with sizable
 lists?

 **· **Do you all know if there is an upper bound of the size of a
 list that can be handled by *ListFindNoCase()*?

 **· **Could this be related to the ValueList itself (the index is
 being the issue)?

 ** **

 Thank you as always for your thoughts!

 ** **

 *Matthew R. Nicholson*

 *SolTech, Inc.*

 *www.soltech.net*

 *(p) 404.601.6000, Ext 233*

 *(c) 770.833.5326*

 *Yes.  We can get you there.* 

 ** **

 -
 To unsubscribe from this list, manage your profile @
 http://www.acfug.org?fa=login.edituserform

 For more info, see http://www.acfug.org/mailinglists
 Archive @ http://www.mail-archive.com/discussion%40acfug.org/
 List hosted by FusionLink http://www.fusionlink.com
 -




-- 
Cameron Childress
--
p:   678.637.5072
im: cameroncf
facebook http://www.facebook.com/cameroncf |
twitterhttp://twitter.com/cameronc |
google+ https://profiles.google.com/u/0/117829379451708140985


RE: [ACFUG Discuss] List Handling

2011-11-02 Thread Matthew Nicholson
I'm always happy to share an example of bad practices! :D

 

All things said and done this solution is far from ideal, which is an
understatement, but I'm always excited to hear options and opinions. 

 

From a high level, this is the current process outlined below in code:

1.   Stored Proc dbo.Orders provides data 

2.   QoQ qryAuto allows us to determine a subset of Orders that meet
specific criteria 

3.   Loop through the QoQ qryAuto to perform specific processes
against specific Orders

4.   If the order doesn't meet those requirements, we then modify
the list autoOrders

5.   Lastly, the autoOrders is used to limit what we display to the
User

 

cfstoredproc procedure=dbo.Orders datasource=#main_dsn#
returncode=yes

  cfprocresult name=Orders resultset=1 /

/cfstoredproc

 

cfquery name=qryAuto dbtype=query

  Select *

  From Orders

  Where Blah Blah Blah

/cfquery

 

CFIF qryAuto.recordCount GT 0

  CFSET autoOrders = ValueList(qryAuto.id, , )

CFELSE

  CFSET autoOrders = 0

/CFIF

 

CFLOOP QUERY=qryAuto

 

  CFIF Check1  Check2  Check3

Do all sorts of goodies

  CFELSE

CFSET pos = ListFindNoCase(autoOrders, id)

CFIF pos NEQ 0

  CFSET autoOrders = ListDeleteAt(autoOrders,pos)

/CFIF

  /CFIF

/CFLOOP

 

In the end, I was curious if I had just run headlong into an issue
because of the use of lists. I will say, the list autoOrders shouldn't
be long long ever as this process is supposed to kick-off
continuously. But, if this is the heart of the issue then a redesign is
obviously necessary.   

 

Thank you all again for your thoughts and insight!

 

Matthew R. Nicholson

SolTech, Inc.

www.soltech.net http://www.soltech.net/ 

(p) 404.601.6000, Ext 233

(c) 770.833.5326

Yes.  We can get you there. 

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Cameron
Childress
Sent: Wednesday, November 02, 2011 2:49 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] List Handling

 

First, as to your actual problem with listFindNoCase() returning 1, I'd
say show your code.  There could be a number of logic problems causing
this.

 

However, I think you are going to run into another problem first.
Because of the way CF handles lists, it's a real REAL bad idea to keep
long lists and loop over them or do other things to them in code.  The
longer a list gets the longer your loop is going to take - not
incrementally, closer to exponentially.

 

ColdFusion treats a list just like a string, and when you ask for item
300, it first has to look for the previous 299 items before it gets to
300. When you ask for item 301?  Yup, goes through all 300 again before
finally settling on item 301.  It's much MUCH better to use an array or
struct or any other sort of structured data.  A ColdFusion list is not
structured, it's just a real long string.

 

I've seen apps that take 60+ seconds to render a page that uses long
lists.  Once converted to arrays, that same page took 1 second to run.

 

Your situation might not be as dire, but the longer your list gets the
worse your potential performance problems are going to get.  Short lists
are fine, but I wouldn't want a 300+ item list floating around being
looped over.  In my previous example, the list was 4,000+ items long.

 

Show your code or describe what you are trying to achieve and perhaps we
can collectively help you find a better way.

 

-Cameron

On Wed, Nov 2, 2011 at 2:35 PM, Matthew Nicholson
matthew.nichol...@soltech.net wrote:

Morning All!

 

I could swear we had a discussion about this awhile ago (although I may
just be remembering an article from Charlie's site).

 

I'm experiencing a bit of a  head scratcher in regards to lists and
managing them. 

1.   Using a QoQ, we create a ValueList from one of its columns

a.   The ValueList is rather sizable list (400+ entries) of
identifiers

2.   We then iterate through the QoQ and do some logic

3.   Should one of those entries (in the loop based upon the QoQ)
not meet the criteria of the logic, we then remove it from the ValueList
previously created ValueList

 

Now, previously, I'd simply search through the list using;

 

ListFindNoCase()

 

And then delete the entry in the ValueList that needed to be removed
using ListDeleteAt(). 

 

However, the rub that I'm experiencing now is that ListFindNoCase()
which worked previously is now only returning 1 when the entry is found
(even if it's obviously not the first entry in the list).

 

Questions!

* Have you all experienced similar problems with sizable lists?

* Do you all know if there is an upper bound of the size of a
list that can be handled by ListFindNoCase()?

* Could this be related to the ValueList itself (the index is
being the issue)?

 

Thank you as always for your thoughts!

 

Matthew R. Nicholson

SolTech, Inc.

www.soltech.net http://www.soltech.net

Re: [ACFUG Discuss] List Handling

2011-11-02 Thread Cameron Childress
First this I see is to try scoping your id var:

CFSET pos = ListFindNoCase(autoOrders, qryAuto.id) 

If the value of id is remaining the same as the first query value, then
it's always going to return 1 as the list position.

You can also output the id value and it's list pos as a debug measure if
you want...  Either inline or using cflog or similar.

cfoutput#id#:#pos#br//cfoutput

If that doesn't uncover your problem, shoot back an email.

-Cameron

On Wed, Nov 2, 2011 at 5:23 PM, Matthew Nicholson 
matthew.nichol...@soltech.net wrote:

 I’m always happy to share an example of bad practices! :D

 ** **

 All things said and done this solution is far from ideal, which is an
 understatement, but I’m always excited to hear options and opinions. 

 ** **

 From a high level, this is the current process outlined below in code:

 **1.   **Stored Proc dbo.Orders provides data 

 **2.   **QoQ qryAuto allows us to determine a subset of Orders that
 meet specific criteria 

 **3.   **Loop through the QoQ qryAuto to perform specific processes
 against specific Orders

 **4.   **If the order doesn’t meet those requirements, we then modify
 the list autoOrders

 **5.   **Lastly, the autoOrders is used to limit what we display to
 the User

 ** **

 cfstoredproc procedure=dbo.Orders datasource=#main_dsn# returncode=
 yes

   cfprocresult name=Orders resultset=1 /

 /cfstoredproc

 ** **

 cfquery name=qryAuto dbtype=query

   *Select* *

   *From* Orders

   *Where* Blah Blah Blah

 /cfquery

 ** **

 CFIF qryAuto.recordCount GT 0

   CFSET autoOrders = ValueList(qryAuto.id, , )

 CFELSE

   CFSET autoOrders = 0

 /CFIF

 ** **

 CFLOOP QUERY=qryAuto

 ** **

   CFIF Check1  Check2  Check3

 Do all sorts of goodies

   CFELSE

 CFSET pos = ListFindNoCase(autoOrders, id)

 CFIF pos NEQ 0

   CFSET autoOrders = ListDeleteAt(autoOrders,pos)

 /CFIF

   /CFIF

 /CFLOOP

 ** **

 In the end, I was curious if I had just run headlong into an issue because
 of the use of lists. I will say, the list autoOrders shouldn’t be “long
 long” ever as this process is supposed to kick-off continuously. But, if
 this is the heart of the issue then a redesign is obviously necessary.   *
 ***

 ** **

 Thank you all again for your thoughts and insight!

 ** **

 *Matthew R. Nicholson*

 *SolTech, Inc.*

 *www.soltech.net*

 *(p) 404.601.6000, Ext 233*

 *(c) 770.833.5326*

 *Yes.  We can get you there.* 

 ** **

 *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Cameron
 Childress
 *Sent:* Wednesday, November 02, 2011 2:49 PM
 *To:* discussion@acfug.org
 *Subject:* Re: [ACFUG Discuss] List Handling

 ** **

 First, as to your actual problem with listFindNoCase() returning 1, I'd
 say show your code.  There could be a number of logic problems causing this.
 

 ** **

 However, I think you are going to run into another problem first.  Because
 of the way CF handles lists, it's a real REAL bad idea to keep long lists
 and loop over them or do other things to them in code.  The longer a list
 gets the longer your loop is going to take - not incrementally, closer to
 exponentially.

 ** **

 ColdFusion treats a list just like a string, and when you ask for item
 300, it first has to look for the previous 299 items before it gets to 300.
 When you ask for item 301?  Yup, goes through all 300 again before finally
 settling on item 301.  It's much MUCH better to use an array or struct or
 any other sort of structured data.  A ColdFusion list is not structured,
 it's just a real long string.

 ** **

 I've seen apps that take 60+ seconds to render a page that uses long
 lists.  Once converted to arrays, that same page took 1 second to run.***
 *

 ** **

 Your situation might not be as dire, but the longer your list gets the
 worse your potential performance problems are going to get.  Short lists
 are fine, but I wouldn't want a 300+ item list floating around being looped
 over.  In my previous example, the list was 4,000+ items long.

 ** **

 Show your code or describe what you are trying to achieve and perhaps we
 can collectively help you find a better way.

 ** **

 -Cameron

 On Wed, Nov 2, 2011 at 2:35 PM, Matthew Nicholson 
 matthew.nichol...@soltech.net wrote:

 Morning All!

  

 I could swear we had a discussion about this awhile ago (although I may
 just be remembering an article from Charlie’s site).

  

 I’m experiencing a bit of a  head scratcher in regards to lists and
 managing them. 

 1.   Using a QoQ, we create a ValueList from one of its columns

 a.   The ValueList is rather sizable list (400+ entries) of
 identifiers

 2.   We then iterate through the QoQ and do some logic

 3

RE: [ACFUG Discuss] List Handling

2011-11-02 Thread Charlie Arehart
Consider also Matthew that it may be helpful to output the autoorders as
well for debugging purposes. It, too, may not be what you expect. 

For instance, if this code is in a CFC method, then you could be having a
situation where other requests are causing conflicts with the variables. If
you've not heard of it as an option, I appreciate that it will sound
far-fetched. Like Cam said, let us know what you think and we can proceed.

 

/charlie

 

From: ad...@acfug.org [mailto:ad...@acfug.org] On Behalf Of Cameron
Childress
Sent: Wednesday, November 02, 2011 6:00 PM
To: discussion@acfug.org
Subject: Re: [ACFUG Discuss] List Handling

 

First this I see is to try scoping your id var:

 

CFSET pos = ListFindNoCase(autoOrders, qryAuto.id) 

 

If the value of id is remaining the same as the first query value, then
it's always going to return 1 as the list position. 

 

You can also output the id value and it's list pos as a debug measure if
you want...  Either inline or using cflog or similar.  

 

cfoutput#id#:#pos#br//cfoutput

 

If that doesn't uncover your problem, shoot back an email.

 

-Cameron

 




-
To unsubscribe from this list, manage your profile @ 
http://www.acfug.org?fa=login.edituserform

For more info, see http://www.acfug.org/mailinglists
Archive @ http://www.mail-archive.com/discussion%40acfug.org/
List hosted by http://www.fusionlink.com
-



Re: [ACFUG Discuss] List Handling

2011-11-02 Thread Steve Ross
I am guessing whatever you are trying to do could be accomplished in sql in
a much more elegant solution... might be wrong but, that would be worth
investigating as well.

On Wed, Nov 2, 2011 at 7:00 PM, Charlie Arehart char...@carehart.orgwrote:

 Consider also Matthew that it may be helpful to output the autoorders as
 well for debugging purposes. It, too, may not be what you expect.

 For instance, if this code is in a CFC method, then you could be having a
 situation where other requests are causing conflicts with the variables. If
 you’ve not heard of it as an option, I appreciate that it will sound
 far-fetched. Like Cam said, let us know what you think and we can proceed.
 

 ** **

 /charlie

 ** **

 *From:* ad...@acfug.org [mailto:ad...@acfug.org] *On Behalf Of *Cameron
 Childress
 *Sent:* Wednesday, November 02, 2011 6:00 PM

 *To:* discussion@acfug.org
 *Subject:* Re: [ACFUG Discuss] List Handling

 ** **

 First this I see is to try scoping your id var:

 ** **

 CFSET pos = ListFindNoCase(autoOrders, qryAuto.id) 

 ** **

 If the value of id is remaining the same as the first query value, then
 it's always going to return 1 as the list position. 

 ** **

 You can also output the id value and it's list pos as a debug measure if
 you want...  Either inline or using cflog or similar.  

 ** **

 cfoutput#id#:#pos#br//cfoutput

 ** **

 If that doesn't uncover your problem, shoot back an email.

 ** **

 -Cameron

 ** **

 -
 To unsubscribe from this list, manage your profile @
 http://www.acfug.org?fa=login.edituserform

 For more info, see http://www.acfug.org/mailinglists
 Archive @ http://www.mail-archive.com/discussion%40acfug.org/
 List hosted by FusionLink http://www.fusionlink.com
 -




-- 
Steve Ross
web application  interface developer
http://blog.stevensross.com
[mobile] (912) 344-8113
[ AIM / Yahoo! : zeriumsteven ] [googleTalk : nowhiding ]