Oliver Jowett wrote:
> I raised this with Barry Lind a while back when I was looking at batch
> updates.
Good to see I'm not the first person to deal with it. Thanks for your
comments.
> There doesn't seem to be an elegant way around it. Ideas:
>
> Option #1: limit the total size of outstanding sent data
This looks like the best bet to me. It is ugly, but at least its ugliness is
confined to one section of code and doesn't have a global impact in the manner
of threads or aborting the whole connection. I'll probably take a look at
this early next week and see what I can come up with.
> This was pretty high on my list of refactoring to do. Also consider
> using a single query executor instance per connection and killing the
> existing static methods -- currently we check the protocol version and
> create a new instance per query which seems entirely unnecessary.
Thanks... yes I'll do that. Since the sending and receiving of queries is
serialized by a monitor on the PGStream anyway, it shouldn't cost anything
this way. Preferably, we could move a lot of protocol-specific code into
these polymorphic classes.
> I'm not so sure about this one though. You run the danger of a lot of
> code duplication here.
Right. I am mainly concerned about AbstractJdbc1Statement and all the
convolutions it goes through with breaking down and transforming the query
into gazillions of forms (server-side prepared statements, cursors, etc.)
Trying to do much with that class while retaining all that state is perhaps
not the best of ideas. But that could possibly be handled by encapsulating
into a separate object, and splitting *that* class into v2 and v3 versions.
Probably much cleaner that way.
> I have some very early interface code I can send you if you'd like to
> take a look.
Sure, I'll take a look. That'd be great.
--
www.designacourse.com
The Easiest Way to Train Anyone... Anywhere.
Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
