Github user arunmahadevan commented on the issue:
https://github.com/apache/storm/pull/1714
@HeartSaVioR I suggested to keep an option to plug our code generator. If
you think calcites code generator (linq4j) addresses all the current cases then
lets go with that. We can revisit
Github user asfgit closed the pull request at:
https://github.com/apache/storm/pull/1714
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user arunmahadevan commented on the issue:
https://github.com/apache/storm/pull/1714
+1
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1714
@arunmahadevan Yes ideally we really want to have it. I just said that
ExprCompiler seems not having a value to keep and maintain. Agreed with you.
Thanks for reviewing!
---
If your project is
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1714
@arunmahadevan
I'm not sure we can have our own expression compiler which supports
features competitive to Calcite. It reminds me why this change is necessary.
We have been leaving
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1591
@hsun-cnnxty
Sorry I lost tracking this.
From the last time I tested on my local machine (via ThroughputVsLatency),
before patching this works better than after patching this. My test
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1727
I'll just merge it since preconditions are met and this change is limited
to documentation.
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user HeartSaVioR commented on the issue:
https://github.com/apache/storm/pull/1725
I'll just merge it since preconditions are met and this change is limited
to documentation.
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Github user asfgit closed the pull request at:
https://github.com/apache/storm/pull/1725
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user asfgit closed the pull request at:
https://github.com/apache/storm/pull/1727
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user arunmahadevan commented on the issue:
https://github.com/apache/storm/pull/1714
@HeartSaVioR with this change we are going to be heavily dependent on the
calcite's code generator to translate expressions correct?. Just thinking if we
should have an option to make the code
Github user srdo closed the pull request at:
https://github.com/apache/storm/pull/1340
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is
Github user srdo commented on the issue:
https://github.com/apache/storm/pull/1340
Closing this, we aren't using this spout anymore and it's a big change to
fix some very minor pausing
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Please allow me to share some of the thoughts on this front:
1. The concepts of monotonic primary key is ensure forward progress for the
query from the relational standpoints -- essentially the results are
append-only streams. The key does not need to be tied to the data itself.
It can be an
14 matches
Mail list logo
