Re: streaming result sets: progress

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