streaming result sets: progress
От | Nic Ferrier |
---|---|
Тема | streaming result sets: progress |
Дата | |
Msg-id | 87r8dzr035.fsf@pooh-sticks-bridge.tapsellferrier.co.uk обсуждение исходный текст |
Ответы |
Re: streaming result sets: progress
Re: streaming result sets: progress Re: streaming result sets: progress Re: streaming result sets: progress Re: streaming result sets: progress |
Список | 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
В списке pgsql-jdbc по дате отправления: