Hi Puneet,

OK, thanks for your information.

*"a) Assume agg1 run on table TestA ;"*

If there is only one group by between source and sink, you can ingest the
output agg result with append mode then followed with a group by to
translate it into update mode(group by uid and do LAST_VALUE agg).

If there are two or more group by between source and sink, this workaround
is not working, because two level group by may output delete messages and
the corresponding key of the delete message may not update again, i.e, the
key may be deleted forever.

* "b) Assume agg2 run on table TestB ;"*

same with a)


2018-01-27 16:09 GMT+08:00 Puneet Kinra <[email protected]>:

> Hi Hequn
>
> Actually we are building a offer management system or real time contextual
> marketing platform. I am creating a poc as of now
> over initial design is some thing like this.
>
> e.g ---
> 1)  2 Sources are registered as as Streaming Table Source.
>          a) Assume *A *with Table Name --*TestA *(append able mode).
>          b) Assume *B* with Table Name --*TestB *(append able mode).
>
> 2) I have set of predefined aggregators  that run on both the tables A and
> B
>          a) Assume *agg1 *run on table *TestA ;*
>          b) Assume *agg2 *run on table *TestB ;*
>
> 3) Now I want to store these aggregators in third table along maintaining
> the "UID" (unique key)
>     not append able mode * then want to run the selection criteria *
>
> *     for instance: select * from TableC where agg1 >0 and agg2>20;*
>
>
>
>
>
>
>
> On Sat, Jan 27, 2018 at 10:27 AM, Hequn Cheng <[email protected]>
> wrote:
>
>> Hi Puneet,
>>
>> I agree with Timo, such a feature should be carefully designed.
>>
>> Besides, I'm very interested with your business scenario. I am wondering
>> where your retraction stream come from (Maybe mysql binlog? or ?).
>> It would be great if you can tell more about the details. Maybe we can
>> figure out a simple workaround.
>>
>> Thanks, Hequn.
>>
>> 2018-01-26 23:08 GMT+08:00 Puneet Kinra <[email protected]
>> >:
>>
>>> Hi
>>>
>>> I know currently Ingesting a table from a retraction stream is not
>>> supported yet.
>>> is there any plan to include in upcoming releases.
>>>
>>> --
>>> *Cheers *
>>>
>>> *Puneet Kinra*
>>>
>>> *Mobile:+918800167808 <+91%2088001%2067808> | Skype :
>>> [email protected] <[email protected]>*
>>>
>>> *e-mail :[email protected]
>>> <[email protected]>*
>>>
>>>
>>>
>>
>
>
> --
> *Cheers *
>
> *Puneet Kinra*
>
> *Mobile:+918800167808 <+91%2088001%2067808> | Skype :
> [email protected] <[email protected]>*
>
> *e-mail :[email protected]
> <[email protected]>*
>
>
>

Reply via email to