mahout-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Owen <>
Subject Re: Getting started
Date Fri, 15 May 2009 16:43:32 GMT
Hmm, tough one. I do write the code in a way that I need to back up in
the ResultSet once in a while, so I need it to be bi-directional. I
had thought FETCH_UNKNOWN was the best way to communicate this, though
by its name, it seems to only say "fetch might be forward or reverse"
not "fetch can be both forward and reverse". I remember adding this
since, I think, MySQL would allow bidirectional access with this
value, but not of course with the default of FETCH_FORWARD.

Clearly this implementation either doesn't support bidirectional
access, or, is still thinking access is forward-only for some reason.

TYPE_SCROLL_INSENSITIVE... seems to be about whether the ResultSet is
worried about new rows appearing during scrolling or something? I
confess I don't know what this is or where it's used; you probably
know more.

1) Can you actually pass TYPE_SCROLL_INSENSITIVE to
setFetchDirection()?? does it work?
2) What about calling setFetchDirection(FETCH_UNKNOWN) on the
ResultSet object itself -- could you try that change locally?
3) else, I will look at ways to avoid backing up in the result set. It
may not be too bad, and, in addition to obviating the problem, might
allow for more efficient DB access.

On Fri, May 15, 2009 at 5:06 PM, Burnett, Adam <> wrote:
> I'm running into another stack trace once I switched to using an OracleDataSource.  AbstractJDBCDataModel
is setting the fetch direction to FETCH_UNKNOWN which causes the ResultSet.isLast() call to
fail. I think using TYPE_SCROLL_INSENSITIVE as the direction should resolve this issue.  Do
you think it makes sense to change this in the abstract data model class or is this a special
case that requires a custom OracleJDBCDataModel?
> Here's the trace:
> java.sql.SQLException: Invalid operation for forward only resultset : isLast

View raw message