Basically we will not perform positioned updates on the hole table data
but for a data portion that it would not exceed 30 rows. That's why I
said it depends on what table we're going through.
But we take care about queries performances.
On 12/26/2015 09:21 AM, Vladimir Sitnikov wrote:
>> we cannot achieve positioned updates using the JDBC implementation
> This is "functional requirement"
>
>> All of these parameters depends on what table we're going through
> Those a "non-functional requirements" (see [1]).
> You'd better collect NFRs *before* you finalize design and write the code.
>
>> Our main problem is
> Suppose you somehow achieved "positional updates". What if it turns
> out to be super-slow? Believe me, there are good reasons for
> "positional updates" to be super slow.
> You would have to rewrite the whole thing from scratch to make it fast.
>
> This is why I do not want to help you to shoot into your own foot.
>
> Anyway, pull requests are welcome.
>
> [1]: https://en.wikipedia.org/wiki/Non-functional_requirement
>
> Vladimir