From: | Nic Ferrier <nferrier(at)tapsellferrier(dot)co(dot)uk> |
---|---|
To: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | streaming result sets: progress |
Date: | 2002-11-06 00:52:30 |
Message-ID: | 87r8dzr035.fsf@pooh-sticks-bridge.tapsellferrier.co.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
I have made quite a bit of progress on the streaming result set
implementation. Unfortunately, I found it too difficult to do without
cleaning up the call path for creating result sets.
My issue was that a streamed ResultSet has to have some way of
re-initing itself with the new results. It also has to be able to run
a new query.
In the current code the ResultSet is a wrapper round an array of
results, it doesn't know much about the database (tho it has a link to
it's owning statement).
In a streamed implementation the ResultSet has to become much more
smart about knowing what it has (well, the logic to do that has to be
somewhere, it seems sensble to put it either in the result set or in
the statement).
I found that there was quite a spread of methods which deal with
generating results, responsibilities are shared between
JdbcConnection, AbstractJdbcConnection, AbstractJdbcStatement and the
result set impl and the QueryExecutor.
My changes made all of these subtle interconnections
unmanageable. I tried to draw some UML of it and failed: just too
many classes.
So what I'm seeking is guidance: should I submit a large patch with
all the changes in? (including changes I've made to clean up the call
path)
Should I first submit patches to clean up the call path? (this is my
preferred option) and then implement the streamed result sets on top
of that?
Should I make a tar available of the source of my changes?
Should I work harder to make my changes fit in with the existing code?
Nic
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Cramer | 2002-11-06 01:59:30 | Re: streaming result sets: progress |
Previous Message | Tom Lane | 2002-11-06 00:11:09 | Re: |