Hi Alexander. What's about supporting statement *INSERT INTO ... SELECT FROM* for streams? Does it make sense?
On Wed, Feb 8, 2017 at 6:44 PM, Alexander Paschenko < alexander.a.pasche...@gmail.com> wrote: > Also, currently it's possible to run SELECTs on "streamed" > connections, and probably this is odd and should not be released too, > what do you think? > > - Alex > > 2017-02-08 18:00 GMT+03:00 Alexander Paschenko > <alexander.a.pasche...@gmail.com>: > > Hello Igniters, > > > > I'd like to raise few questions regarding data streaming via DML > statements. > > > > Currently, all types of DML statements are supported (INSERT, UPDATE, > > DELETE, MERGE). > > > > UPDATE and DELETE are supported in streaming mode only when their > > WHERE condition is bounded with _key and/or _val columns, and UPDATE > > works only for _val column directly. > > > > Seeing some activity in direction of hiding _key and _val from the > > user as far as possible, these features seem pointless and should not > > be released, what do you think? > > > > Also INSERT in streaming mode currently does not throw errors on > > duplicate keys and silently ignores such new records (as long as it's > > faster than it would work if we'd introduced receiver that would throw > > exceptions) - this can be fixed with additional flag that could > > _optionally_ make INSERT slower but more accurate in semantic. > > > > And MERGE in streaming mode currently not totally accurate in > > semantic, too - on key presence, it will just replace whole value with > > new one thus potentially making values of some concrete columns/fields > > lost - this is analogous to > > https://issues.apache.org/jira/browse/IGNITE-4489, but hardly can be > > fixed as long as probably it would hit performance and would be > > unresonably complex to implement. > > > > I suggest that we drop all except INSERT and introduce optional flag > > for its totally correct semantic behavior as described above. > > > > - Alex > -- Sergey Kozlov GridGain Systems www.gridgain.com