DO NOT REPLY [Bug 7181] - esql:group behaves erratically

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7181>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=7181

esql:group behaves erratically





------- Additional Comments From [EMAIL PROTECTED]  2002-03-18 10:29 -------
Hello all,

the modified query that Tim posted still doesn't work for me :-(  The simple
<esql:get-columns/> works fine with column aliases on a jdbc-odbc datasource,
returning the specified aliases as column names, 

<esql:execute-query>
  <esql:query>
    SELECT department.name as deptName, employee.id, employee.name as empName 
    FROM department, employee
    WHERE department.id = employee.department_id  ORDER BY department.name
  </esql:query>
  <esql:results>
    <esql:row-results>
      <esql:group group-on='deptName'>
        <Department><xsp:attribute name='name'><esql:get-string
column='deptName'/></xsp:attribute>
        <esql:member>
          <employee><esql:get-string column='empName'/></employee>
        </esql:member>
        </Department>
      </esql:group>
    </esql:row-results>
  </esql:results>
</esql:execute-query>

When I use the <esql:group> tag I still get malformed XML:

        <content>
                <Department name="Development">
        </content>

I delved more into the code and found that EsqlQuery.groupingVars is a
Hashtable. The values are being provided by the XSP-generated java class as:

_esql_query.setGroupingVar("deptNameOld",
_esql_query.getResultSet().getString("deptName"));

the decision point to find if the next value is in the same group is:

((String)_esql_query.getGroupingVar("deptNameOld")).equals(_esql_query.getResultSet().getString("deptName"))

Now, I am no JDBC expert, but isn't this ResultSet.getString() supposed to
return a reference to the current row's value? wouldn't resultSet.next()
invalidate it?

And an architectural comment: why do we have to continiously pass field values
between the XSP page and EsqlQuery.java? wouldn't the grouping code be cleaner
if it was placed inside EsqlQuery.java? Instead of splitting the grouping logic
between the logicsheet and EsqlQuery, why not let EsqlQuery.nextRow() decide
which groups changed and which didn't?

I am _very_ new to Cocoon, so I don't know if I could change things without
messing up... Are there any specific reasons _not_ to keep the grouping code
inside EsqlQuery.java?

Elias

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]