Scott Lamb <slamb@slamb.org> writes:
> Nic said:
> > That would mean that we didn't need the fetch size signal. Or we
> > could use the fetchSize signal as well.
>
> I'm not sure that would work anyway. It's ResultSet.setFetchSize(),
> which means you must already have a resultset when to change it. So it
> seems like it'd be a little late for deciding how to execute the
> query.
We don't use that "setFetchSize" we use Statement.setFetchSize.
The setFetchSize in ResultSet has an effect, but as you say, not on
the type of the ResultSet /8->
> > Note also that CLOSE_CURSORS_AT_COMMIT is not actually a result set
> > type so it _might_ break other code.
>
> Not sure what you mean. If client code is using CLOSE_CURSORS_AT_COMMIT
> and expecting them to work beyond commit, it's their bug and an
> easily-fixed one at that. And I don't see any other negative
> consequences to using cursors, just the advantage of being able to
> handle large queries.
That's not what I was saying.
It's easier if I express this in pseudo-C:
enum resultset_types
{
TYPE_FORWARD_ONLY
TYPE_SCROLL_INSENSITIVE
TYPE_SCROLL_SENSITIVE
};
So CLOSE_CURSORS_AT_COMMIT is not a _normal_ value for the ResultSet
_type_ type.
The real problem with this is that Java does not have enums, witness
the code from GNU Classpath's java.sql implementation:
>>>>
public static final int TYPE_FORWARD_ONLY = 0;
public static final int TYPE_SCROLL_INSENSITIVE = 1;
public static final int TYPE_SCROLL_SENSITIVE = 1;
public static final int CONCUR_READ_ONLY = 0;
public static final int CONCUR_UPDATABLE = 1;
<<<<
Oops. Not sure how we'll get round that if we follow your suggestion.
Any ideas?
Nic
