|
On 05/07/2006, at 10:47 AM, Joe Pluta wrote:
From: Simon CoulterI'm a little confused (not that that's unusual). What do you mean "iteratethrough each column"? The ResultSet in JDBC has a next() method whichpositions you to the next row, at which point you do getXxx (e.g., getString, getFloat) passing either an ordinal column number or a Stringcontaining a column name to get the appropriate field from the currentrow. I don't have to iterate through the columns.You do. Issuing a GetXxx for each column in a row is effectively the same as iterating over those columns, determining the data type, and extracting it accordingly.No, it's not "effectively the same".
Yes it is.
It's very different.
No it's not.
From Wikipedia:"An iterator may be thought of as a type of pointer which has two primaryoperations: referencing one particular element in the collection object (called element access), and modifying itself so it points to the next element (called element traversal)."
That's an Iterator object. Such an object is NOT necessary to implement iteration. Iteration is simply looping over a number of elements--in this case the columns of a result set.
An Iterator object just hides the looping. When using the QSQPRCED API the programmer is responsible for looping over the column information.
Note the word "next". Iterating in the computer sense is to process a listof objects sequentially, one at a time; there's not even an implicitcapability of going backward. In fact, the next() method in the ResultSet is a good example of iterating: I can't get to the third record without at least positioning to the first and second. You can think of iterating assequential access.
Oh duh! Have you taught any Granny's about egg sucking lately? Tell me something I don't know. That definition doesn't add anything of value to this discussion.
next() implies a forward motion but iteration doesn't. I can iterate over a list forwards or backwards as I see fit. In any decent implementation I should be able to change direction part way through. If the list is simply an array then I can also easily start at any position in the list. I don't have to start at the beginning or the end.
The getXxx() methods, on the other hand, are more analogous to randomaccess; I can get fields in any order I wish, processing whichever fields I wish and completely ignoring others. I can get the third field, then theseventh, then the second.Thus the term "iterate" when talking about accessing columns seems somewhatunclear to me.
That's because you're not thinking properly. Consider a Java application that could process ANY file. It doesn't know the file nor the column attributes until run-time therefore the programmer cannot code specific getXxxx function calls. It becomes necessary to retrieve the file meta-data and ITERATE over the column information. Once the column data type has been determined the appropriate getXxxx function can be invoked. The obvious way to implement the ITERATION is via a loop for the number of columns. You might want to encapsulate that looping process but it doesn't change the fundamental fact that iteration is required when the column attributes are not known until run-time. This is exactly the same processing technique as required when using the QSQPRCED API or the SQL DA.
Consider how the getXxx functions might be implemented. They might use the column name as a key to lookup the associated column number or they might simply ITERATE over the meta-data until they find a matching name. They might use the column number as an index into the meta-data or they might ITERATE until they find the matching element. It really doesn't matter HOW they actually locate the column information (except for performance and that doesn't affect the concepts). Without looking at the code you can't know whether the getXxxx functions implement random access or sequential access and it doesn't matter for the purposes of this discussion.
Consider the case where all columns have the same data type. Instead of coding a list of getXxx calls for each column I could loop for the number of columns and have one getString call populate an array of String elements.
Now consider that a sequence of getString calls is simply an unrolled loop and you should be able to see that iterating over the columns, and calling a sequence of getXxxx functions is "effectively the same".
There is no practical difference between writing a loop to determine the column type then calling an appropriate extraction function, and hard-coding the extraction calls because the programmer happens to "know" the data types for each column. Thus we are back to my original statement that they are "effectively the same" because the result is the same. If the result is the same then the "effect" must be the same. QED!
However, I know you won't agree and because you've taken a contrary position you'll just have to continue arguing that position until we all get fed up. This isn't a "right" or "wrong" thing. Larry was drawing a valid comparison which you didn't understand due to a rather literal interpretation of a limited implementation.
Regards, Simon Coulter. -------------------------------------------------------------------- FlyByNight Software AS/400 Technical Specialists http://www.flybynight.com.au/ Phone: +61 3 9419 0175 Mobile: +61 0411 091 400 /"\ Fax: +61 3 9419 0175 \ / X ASCII Ribbon campaign against HTML E-Mail / \ --------------------------------------------------------------------
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
