Nic,
You should send us diff's of everything, we don't have to apply all of
them at once, but we will be able to see where you are going.
Dave
On Tue, 2002-11-05 at 19:52, Nic Ferrier wrote:
> 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
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
--
Dave Cramer <Dave@micro-automation.net>
