RE: [ACFUG Discuss] List Handling
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
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
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
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
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
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
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 ]