Re: looking for architectural advice for dealing with streams/LOBS as inputs to UPDATE operations

2013-07-13 Thread Kristian Waagan
torsdag 6. juni 2013 skrev Knut Anders Hatlen følgende: mike matrigali mikema...@gmail.com javascript:; writes: Recent investigation for DERBY-6214 uncovered a problem with streams/LOBS as inputs to UPDATE statements. The problem occurs when the update affects more than one row, causing

Re: looking for architectural advice for dealing with streams/LOBS as inputs to UPDATE operations

2013-06-06 Thread Knut Anders Hatlen
mike matrigali mikema...@gmail.com writes: Recent investigation for DERBY-6214 uncovered a problem with streams/LOBS as inputs to UPDATE statements. The problem occurs when the update affects more than one row, causing the system to read the input once for each row, and finds that the

looking for architectural advice for dealing with streams/LOBS as inputs to UPDATE operations

2013-06-05 Thread mike matrigali
Recent investigation for DERBY-6214 uncovered a problem with streams/LOBS as inputs to UPDATE statements. The problem occurs when the update affects more than one row, causing the system to read the input once for each row, and finds that the stream is closed after being drained once. First

Re: looking for architectural advice for dealing with streams/LOBS as inputs to UPDATE operations

2013-06-05 Thread Dag Wanvik
It seems to be that if the compiler determines the update is not on a unique row, it should save the stream while reading it, either to memory or on disk if it gets too large. The latter may not be decidable up front, so one can envisage cutting off moving it to memory at some cut-off limit, and