>I'm interested in the STREAM case. My question is, if you use the STREAM >keyword (either after SELECT or at the end), which of the tables is treated >as a stream? Order_item, product or both?
Does it matter which table is a steam? if the "STREAM" query runs continuously, the output (table) from the query is a stream, and likely this stream gives you delta updates periodically. Theoretically, "STREAM" can work when both order_item and product are not "stream", in that case I believe this query just give your one update, which is the full result since all data have been processed. Whether order_item or product is a "steam" depends on its source. E.g. if order_time is from Kafka, usually it's treated as a "stream". If product is from mysql, usually it's treated as "table". -Rui On Fri, Mar 20, 2020 at 1:44 PM Viliam Durina <[email protected]> wrote: > Without the STREAM keyword it's clear, it's the old-fashioned SQL, no issue > there. > > I'm interested in the STREAM case. My question is, if you use the STREAM > keyword (either after SELECT or at the end), which of the tables is treated > as a stream? Order_item, product or both? > > Viliam > > On Fri, 20 Mar 2020 at 21:30, Julian Hyde <[email protected]> wrote: > > > I should have said that > > > > SELECT * FROM order_item o JOIN product p USING(product_id) > > > > (without the "STREAM" keyword) is a time-varying relation. You can > > execute it at 10am, and it terminates, and again at 10.10am and get > > different results. The difference is due to differences in both > > product and order_item. > > > > If you want to join based on when the order was placed, you must have > > a column that records the order time. Beyond that, I'm not sure of the > > details - you may be able to use AS OF, there may be a > > system-maintained column that records when product was last updated. > > > > Julian > > > > On Fri, Mar 20, 2020 at 12:01 AM Viliam Durina <[email protected]> > > wrote: > > > > > > On Thu, 19 Mar 2020 at 21:04, Julian Hyde <[email protected]> wrote: > > > > > > Suppose you execute that query at 10am and get a particular result. ... > > you > > > > execute again at 10.10am. > > > > > > > > > > I execute that query at 10am and expect it to run continuously. My > > > understanding is that a query with `EMIT STREAM` will run continuously. > > > Does it just fetch results and finish? > > > > > > Now, if you have particular time-sensitive join semantics - such as > > wanting > > > > to join the order_item to the product table as if was at the time the > > order > > > > was placed - you will need to express that explicitly in the join > > condition. > > > > > > > > > > How would such a query look? Could you write it? There's no time column > > in > > > either relation. > > > > > > Regards, > > > Viliam > > > > > > -- > > > This message contains confidential information and is intended only for > > the > > > individuals named. If you are not the named addressee you should not > > > disseminate, distribute or copy this e-mail. Please notify the sender > > > immediately by e-mail if you have received this e-mail by mistake and > > > delete this e-mail from your system. E-mail transmission cannot be > > > guaranteed to be secure or error-free as information could be > > intercepted, > > > corrupted, lost, destroyed, arrive late or incomplete, or contain > > viruses. > > > The sender therefore does not accept liability for any errors or > > omissions > > > in the contents of this message, which arise as a result of e-mail > > > transmission. If verification is required, please request a hard-copy > > > version. -Hazelcast > > > > > -- > Viliam Durina > Jet Developer > hazelcast® > > <https://www.hazelcast.com> 2 W 5th Ave, Ste 300 | San Mateo, CA 94402 | > USA > +1 (650) 521-5453 <(650)%20521-5453> | hazelcast.com < > https://www.hazelcast.com> > > -- > This message contains confidential information and is intended only for > the > individuals named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. E-mail transmission cannot be > guaranteed to be secure or error-free as information could be intercepted, > corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. > The sender therefore does not accept liability for any errors or omissions > in the contents of this message, which arise as a result of e-mail > transmission. If verification is required, please request a hard-copy > version. -Hazelcast >
