Re: Type Inference and Nullability set/change

[Julian Hyde]

What Danny says is correct. Type inference is built into each 
operator/function, so if you want to customize type inference, you basically 
need to create a new set of operators/functions.

I’ll add that there is interface RelDataTypeSystem, which allows you to 
customize properties of built-in types and key built-in operators, such as the 
result type of division or addition of decimals. But we do not extend that 
interface without good cause.

Julian
 

> On Oct 24, 2019, at 8:19 PM, Dustin Freeman  wrote:
> 
> Hi Danny,
> 
> Thanks very much for quick response.  Basically, you are saying that there
> are not ways to change type inference rules. The only way to do that is to
> write your own type inference functions for some specific calls, then use
> RexShuttle to re-do type inference.
> 
> Dustin
> 
> 
> On Thu, Oct 24, 2019 at 8:09 PM Danny Chan  wrote:
> 
>> Dustin ~
>> 
>> The type inference for all kinds of operator/functions are defined by 2
>> kinds of components in Calcite:
>> 
>> 
>> • The SqlOperandTypeChecker infers the operands data types
>> • The SqlReturnTypeInference infers the return data type of the call
>> 
>> That means the type inference strategy is fixed and AFAIK, there is no way
>> to change it dynamically, the strategy is registered statically with the
>> function/operator.
>> 
>> If you want to explicit specify the all the integer literals should be
>> INT64(BIGINT) type, you can use a RexShuttle to visit all the rexCalls and
>> rewrite your relational expression.
>> 
>> Best,
>> Danny Chan
>> 在 2019年10月25日 +0800 AM10:46，Dustin Freeman ，写道：
>>> Hi All,
>>> 
>>> After I translate a query (SQL text) into a RelNode Tree like this,
>>> 
>>> RelNode res = planner.getLogicalPlan(getSqlText());
>>> 
>>> What's the simplest way to do/change type inference and set nullability
>> for
>>> all expressions in node res?
>>> 
>>> It seems that RelNode has some type info already like below. It seems
>> both
>>> constants should have a data type int64, rather than int32. A conversion
>>> there is needed. That conversion could be simplified to (const int64)1).
>>> Anyways to let Calcite to do such changes?
>>> 
>>> bool greater_than(int64 minus((int64) PID, *(const int32) 1)*, (const
>>> int32) 100)
>>> 
>>> 
>>> Thanks,
>>> 
>>> Dustin
>> 

Re: Type Inference and Nullability set/change

[Dustin Freeman]

Hi Danny,

Thanks very much for quick response.  Basically, you are saying that there
are not ways to change type inference rules. The only way to do that is to
write your own type inference functions for some specific calls, then use
RexShuttle to re-do type inference.

Dustin


On Thu, Oct 24, 2019 at 8:09 PM Danny Chan  wrote:

> Dustin ~
>
> The type inference for all kinds of operator/functions are defined by 2
> kinds of components in Calcite:
>
>
> • The SqlOperandTypeChecker infers the operands data types
> • The SqlReturnTypeInference infers the return data type of the call
>
> That means the type inference strategy is fixed and AFAIK, there is no way
> to change it dynamically, the strategy is registered statically with the
> function/operator.
>
> If you want to explicit specify the all the integer literals should be
> INT64(BIGINT) type, you can use a RexShuttle to visit all the rexCalls and
> rewrite your relational expression.
>
> Best,
> Danny Chan
> 在 2019年10月25日 +0800 AM10:46，Dustin Freeman ，写道：
> > Hi All,
> >
> > After I translate a query (SQL text) into a RelNode Tree like this,
> >
> > RelNode res = planner.getLogicalPlan(getSqlText());
> >
> > What's the simplest way to do/change type inference and set nullability
> for
> > all expressions in node res?
> >
> > It seems that RelNode has some type info already like below. It seems
> both
> > constants should have a data type int64, rather than int32. A conversion
> > there is needed. That conversion could be simplified to (const int64)1).
> > Anyways to let Calcite to do such changes?
> >
> > bool greater_than(int64 minus((int64) PID, *(const int32) 1)*, (const
> > int32) 100)
> >
> >
> > Thanks,
> >
> > Dustin
>

Re: Type Inference and Nullability set/change

[Danny Chan]

Dustin ~

The type inference for all kinds of operator/functions are defined by 2 kinds 
of components in Calcite:


• The SqlOperandTypeChecker infers the operands data types
• The SqlReturnTypeInference infers the return data type of the call

That means the type inference strategy is fixed and AFAIK, there is no way to 
change it dynamically, the strategy is registered statically with the 
function/operator.

If you want to explicit specify the all the integer literals should be 
INT64(BIGINT) type, you can use a RexShuttle to visit all the rexCalls and 
rewrite your relational expression.

Best,
Danny Chan
在 2019年10月25日 +0800 AM10:46，Dustin Freeman ，写道：
> Hi All,
>
> After I translate a query (SQL text) into a RelNode Tree like this,
>
> RelNode res = planner.getLogicalPlan(getSqlText());
>
> What's the simplest way to do/change type inference and set nullability for
> all expressions in node res?
>
> It seems that RelNode has some type info already like below. It seems both
> constants should have a data type int64, rather than int32. A conversion
> there is needed. That conversion could be simplified to (const int64)1).
> Anyways to let Calcite to do such changes?
>
> bool greater_than(int64 minus((int64) PID, *(const int32) 1)*, (const
> int32) 100)
>
>
> Thanks,
>
> Dustin

Type Inference and Nullability set/change

[Dustin Freeman]

Hi All,

After I translate a query (SQL text) into a RelNode Tree like this,

RelNode res = planner.getLogicalPlan(getSqlText());

What's the simplest way to do/change type inference and set nullability for
all expressions in node res?

It seems that RelNode has some type info already like below. It seems both
constants should have a data type int64, rather than int32. A conversion
there is needed. That conversion could be simplified to (const int64)1).
Anyways to let Calcite to do such changes?

bool greater_than(int64 minus((int64) PID, *(const int32) 1)*, (const
int32) 100)


Thanks,

Dustin

Re: Redirecting to https

[Danny Chan]

Sounds cool, hope it works perfectly !

Best,
Danny Chan
在 2019年10月25日 +0800 AM4:23，Julian Hyde ，写道：
> Thanks for the suggestions. I’ve logged 
> https://issues.apache.org/jira/browse/CALCITE-3445 
> . I’ll try to get to it, 
> but feel free to jump in.
>
> > On Oct 23, 2019, at 6:26 PM, Michael Mior  wrote:
> >
> > Great! Seems like we could just take lines 1-15 and change beam to
> > calcite and we would be set. Glad to see this discussion brought up
> > and I think we should make this change.
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le mer. 23 oct. 2019 à 18:45, Francis Chuang
> >  a écrit :
> > >
> > > I think we can do this using a .htaccess file (all ASF sites run on the
> > > Apache HTTPD).
> > >
> > > See Cordova's change to do this:
> > > https://github.com/apache/cordova-docs/commit/fcfd9ffafca5547f6859a0bd662db6341b15da34
> > >
> > > And Beam's:
> > > https://github.com/apache/beam/blob/master/website/src/.htaccess#L12
> > >
> > > On 24/10/2019 9:38 am, Julian Hyde wrote:
> > > > When you go to http://calcite.apache.org it does not automatically
> > > > redirect to https://calcite.apache.org.
> > > >
> > > > Does anyone know how we would accomplish this?
> > > >
> > > > I notice that http://beam.apache.org does the right thing.
> > > >
> > > > Julian
> > > >
>

Re: Re: [DISCUSS] On-demand traitset request

[Danny Chan]

I have the same feeling, it seems to much interfaces for the physical node(we 
do not really have physical class for physical nodes yet), so these interfaces 
may just be put into the RelNode, that was too complex and to much for me, can 
we have a way that do not modify the nodes itself ?

Best,
Danny Chan
在 2019年10月23日 +0800 PM2:53，Stamatis Zampetakis ，写道：
> Overall, I agree that better encapsulation of propagation and derivation of
> traits would be beneficial for our system.
>
> Regarding the API proposed by Haisheng, I have to think a bit more on it.
> At first glance, adding such methods directly in the RelNode API does not
> appear an ideal solution since I don't see how easily it can be extended to
> support other kinds of traits.
>
> Best,
> Stamatis
>
> On Mon, Oct 21, 2019 at 7:31 AM Haisheng Yuan 
> wrote:
>
> > To Stamatis,
> > Not exactly. My initial thought was giving the physical operator the
> > abiity to customize and fully control physical property derivation
> > strategy, thus can further help the purpose driven trait request. But since
> > we agree to think more high-level API to support on-demand traitset
> > request, I will illustrate what API is expected from implentator's
> > perspective.
> >
> > Jingfeng gave us basic steps on how the plan might be generated using
> > top-down purpose driven only manner, I think differently with the first
> > several steps.
> >
> > SELECT DISTINCT c, b FROM
> > ( SELECT R.c c, S.b b FROM R, S
> > WHERE R.a=S.a and R.b=S.b and R.c=S.c) t;
> >
> > Aggregate . (c, b)
> > +--- MergeJoin . (a, b, c)
> > |--- TableScan on R
> > +-- TableScan on S
> >
> > 1. Aggreate require collation (c,b) from its child, not permutation.
> > 2. MergeJoin's parent require (c,b), it has 2 options. Pass it down, or
> > ignore it.
> > a) Pass down. it has join condition on (a,b,c), the required columns
> > can be coverd by join condition columns, so MergeJoin will try to deliver
> > (c,b,a), and both children must exact match. Then we will have sort on both
> > children of MergeJoin.
> > b) Ignore it. Require its first child collation on (a,b,c), but
> > matching type is subset. R delivers (c,b,a). Then using the first child's
> > derived collation trait to require its second child to exact match. Thus we
> > have a sort on S, and a sort on top of MergeJoin.
> >
> > Both plan might be good or bad. If R, S are large, but the join result is
> > small, plan b) might be better, otherwise plan a) might be better.
> >
> > Anyway, I hope the physical operators can have full control the physical
> > properties requests and derivation, in physical operator class itself, not
> > rules, not other places.
> >
> > Per our experience, we have spent too much time on writing code for
> > dealing with all kinds of property requirement and derivation. But in fact,
> > life should be easier. I would like to the physical operator provides the
> > following API, and the 3rd party implementator just need to
> > override/implement them, no more need to be taken care.
> >
> > 1. void setDistributionRequests(int numReq)
> > Each operator can specify how many optimzation requests on some trait it
> > want to do. e.g. HashJoin may request the following distribution on both
> > children:
> > - (hash distribution on key1, hash distribution on key1)
> > - (hash distribution on key2, hash distribution on key2)
> > - (hash distribution on all keys, hash distribution on all keys)
> > - (Any, Broadcast)
> > - (Gather, Gather)
> >
> > 2. RelDistribution requiredDistribution(RelDistribution required, int
> > child) //same for collation
> > Given the required distribution from parent operator, returns the required
> > distribution for its nth child.
> >
> > 3. RelDistribution derivedDistribution() //same for collation
> > Derive the distribution of the operator itelf from child operators.
> >
> > 4. MatchType distributionMatchType(int child) //same for collation
> > Returns the distribution match type for its nth child, how does it match
> > the other children.
> > Similar with Jinfeng's point, I think there should be 3 types of matching:
> > exact, satisfy, subset.
> > e.g.
> > R is distributed by (a), S is distributed by (a,b)
> > select * from R join S using a,b,c
> > If we have plan
> > HashJoin
> > |-- TableScan on R
> > +-- TableScan on S
> > We may require the match type on S to be satisfy. (a,b) satisfies required
> > distribution (a,b,c).
> > Fot the outer child R, we require it to be exact match with inner.
> >
> > 5. ExecOrder getExecOrder()
> > Returns how the operator's children is executed, left to right, or right
> > to left. Typically, hash join is right to left. We might use this as the
> > optimization order. To make sure we have correct plans, we have to optimize
> > child and enforce properties in the order that is specific to the physical
> > operator.
> > All the other dirty work should be done by the optimization engine, but
> > not through rules, I believe. However, I havn't got any 

Re: [DISCUSSION] Extension of Metadata Query

[Danny Chan]

I have created a JIRA issue https://issues.apache.org/jira/browse/CALCITE-3446 
and start working ~

Best,
Danny Chan
在 2019年10月25日 +0800 AM9:02，Julian Hyde ，写道：
> Sure.
>
> Let’s have a test that creates such a sub-class. Then people can use it as an 
> example.
>
> Also, let’s make sure that a sub-sub-class of RelMetadataQuery also works.
>
> Perhaps split RelMetadataQuery into a base class (containing the essential 
> mechanism) and a derived class (containing the handlers and methods for each 
> kind of built-in metadata). It will be interesting to see which code needs 
> the derived class and how which code needs only the base class.
>
> Julian
>
>
> > On Oct 24, 2019, at 4:56 PM, Haisheng Yuan  wrote:
> >
> > Sounds like we have reached a consensus, I guess.
> > Can we create a JIRA to allow users to create their own sub-class of 
> > RelMetadataQuery?
> >
> > - Haisheng
> >
> > --
> > 发件人：Julian Hyde
> > 日　期：2019年10月22日 09:58:34
> > 收件人：dev
> > 主　题：Re: [DISCUSSION] Extension of Metadata Query
> >
> > Yes, the division of labor between MetadataFactory and RelMetadataQuery is 
> > a good one, and we should keep them intact. One provides the raw metadata, 
> > and the other provides a typed interface and transactions/caching.
> >
> > It might be allowable for a user to create their own sub-class of 
> > RelMetadataQuery that adds only handler fields and metadata methods, 
> > provided that it follows the existing pattern. We could add a new 
> > thread-local in RelMetadataQuery.instance() that is a factory to create the 
> > required sub-class of RelMetadataQuery.
> >
> > The process by which metadata factories re-generate themselves is delicate 
> > and subtle:
> >
> > public Double getMaxRowCount(RelNode rel) {
> > for (;;) {
> > try {
> > return maxRowCountHandler.getMaxRowCount(rel, this);
> > } catch (JaninoRelMetadataProvider.NoHandler e) {
> > maxRowCountHandler =
> > revise(e.relClass, BuiltInMetadata.MaxRowCount.DEF);
> > }
> > }
> > }
> >
> > (Note that “revise” generates a new class, creating bytecode via janino, 
> > and the generated code throws “NoHandler" when it needs to extend itself.) 
> > I don’t trust the typical Calcite user to be able to write a sub-class that 
> > works correctly and efficiently.
> >
> > Julian
> >
> >
> >
> > > On Oct 18, 2019, at 3:55 AM, XING JIN  wrote:
> > >
> > > +1 on Danny's comment.
> > > If we use MedataFactory to customize and use RelMetadataQuery for
> > > convenience, that will make user confused.
> > >
> > > Danny Chan  于2019年10月18日周五 下午12:33写道：
> > >
> > > > That is the point, we should supply a way to extend the RelMetadataQuery
> > > > conveniently for Calcite, because in most of the RelOptRules, user would
> > > > use the code like:
> > > >
> > > > RelOptRuleCall.getMetadataQuery
> > > >
> > > > To get a RMQ instead of using AbstractRelNode.metadata() to fetch a
> > > > MedataFactory.
> > > >
> > > > We should at lest unity the metadata query entrance/interfaces, or it
> > > > would confuse a lot.
> > > >
> > > > Best,
> > > > Danny Chan
> > > > 在 2019年10月18日 +0800 AM12:23，Seliverstov Igor ，写道：
> > > > > At least in our project (Apache Ignite) we use
> > > > AbstractRelNode.metadata().
> > > > >
> > > > > But it so because there is no way to put our metadata type into
> > > > > RelMetadataQuery without changes in Calcite.
> > > > >
> > > > > Regards,
> > > > > Igor
> > > > >
> > > > > чт, 17 окт. 2019 г., 19:16 Xiening Dai :
> > > > >
> > > > > > MetadataFactory is still useful. It provides a way to access 
> > > > > > Metadata
> > > > > > directly. If someone creates a new type of Metadata class, it can be
> > > > > > accessed through AbstractRelNode.metadata(). This way you don’t 
> > > > > > need to
> > > > > > update RelMetadataQuery interface to include the getter for this new
> > > > meta.
> > > > > > Although I don’t see this pattern being used often, but I do think 
> > > > > > it
> > > > is
> > > > > > still useful and shouldn’t be removed.
> > > > > >
> > > > > >
> > > > > > For your second point, I think you would still need a way to keep
> > > > > > RelMetadataQuery object during a rule call. If you choose to create 
> > > > > > new
> > > > > > instance, you will have to pass it around while applying the rule. 
> > > > > > That
> > > > > > actually complicates things a lot.
> > > > > >
> > > > > >
> > > > > > > On Oct 17, 2019, at 12:49 AM, XING JIN 
> > > > wrote:
> > > > > > >
> > > > > > > 1. RelMetadataQuery covers the functionality of MetadataFactory, 
> > > > > > > why
> > > > > > should
> > > > > > > we keep/maintain both of them ? shall we just deprecate
> > > > MetadataFactory.
> > > > > > I
> > > > > > > see MetadataFactory is rarely used in current code. Also I
> > > > > > > think MetadataFactory is not good place to offering customized
> > > > metadata,
> > > > > > > which will make user confused for the difference between
> > > > RelMetadataQuery
> > > > > 

[jira] [Created] (CALCITE-3446) Make RelMetadataQuery extendible

[Danny Chen (Jira)]

Danny Chen created CALCITE-3446:
---

 Summary: Make RelMetadataQuery extendible
 Key: CALCITE-3446
 URL: https://issues.apache.org/jira/browse/CALCITE-3446
 Project: Calcite
  Issue Type: Improvement
  Components: core
Affects Versions: 1.21.0
Reporter: Danny Chen
Assignee: Danny Chen
 Fix For: 1.22.0






--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: [DISCUSSION] Extension of Metadata Query

[Julian Hyde]

Sure.

Let’s have a test that creates such a sub-class. Then people can use it as an 
example. 

Also, let’s make sure that a sub-sub-class of RelMetadataQuery also works.

Perhaps split RelMetadataQuery into a base class (containing the essential 
mechanism) and a derived class (containing the handlers and methods for each 
kind of built-in metadata). It will be interesting to see which code needs the 
derived class and how which code needs only the base class.

Julian


> On Oct 24, 2019, at 4:56 PM, Haisheng Yuan  wrote:
> 
> Sounds like we have reached a consensus, I guess.
> Can we create a JIRA to allow users to create their own sub-class of 
> RelMetadataQuery?
> 
> - Haisheng
> 
> --
> 发件人：Julian Hyde
> 日　期：2019年10月22日 09:58:34
> 收件人：dev
> 主　题：Re: [DISCUSSION] Extension of Metadata Query
> 
> Yes, the division of labor between MetadataFactory and RelMetadataQuery is a 
> good one, and we should keep them intact. One provides the raw metadata, and 
> the other provides a typed interface and transactions/caching.
> 
> It might be allowable for a user to create their own sub-class of 
> RelMetadataQuery that adds only handler fields and metadata methods, provided 
> that it follows the existing pattern. We could add a new thread-local in 
> RelMetadataQuery.instance() that is a factory to create the required 
> sub-class of RelMetadataQuery.
> 
> The process by which metadata factories re-generate themselves is delicate 
> and subtle:
> 
> public Double getMaxRowCount(RelNode rel) {
> for (;;) {
> try {
> return maxRowCountHandler.getMaxRowCount(rel, this);
> } catch (JaninoRelMetadataProvider.NoHandler e) {
> maxRowCountHandler =
> revise(e.relClass, BuiltInMetadata.MaxRowCount.DEF);
> }
> }
> }
> 
> (Note that “revise” generates a new class, creating bytecode via janino, and 
> the generated code throws “NoHandler" when it needs to extend itself.) I 
> don’t trust the typical Calcite user to be able to write a sub-class that 
> works correctly and efficiently.
> 
> Julian
> 
> 
> 
> > On Oct 18, 2019, at 3:55 AM, XING JIN  wrote:
> > 
> > +1 on Danny's comment.
> > If we use MedataFactory to customize and use RelMetadataQuery for
> > convenience, that will make user confused.
> > 
> > Danny Chan  于2019年10月18日周五 下午12:33写道：
> > 
> >> That is the point, we should supply a way to extend the RelMetadataQuery
> >> conveniently for Calcite, because in most of the RelOptRules, user would
> >> use the code like:
> >> 
> >> RelOptRuleCall.getMetadataQuery
> >> 
> >> To get a RMQ instead of using AbstractRelNode.metadata() to fetch a
> >> MedataFactory.
> >> 
> >> We should at lest unity the metadata query entrance/interfaces, or it
> >> would confuse a lot.
> >> 
> >> Best,
> >> Danny Chan
> >> 在 2019年10月18日 +0800 AM12:23，Seliverstov Igor ，写道：
> >>> At least in our project (Apache Ignite) we use
> >> AbstractRelNode.metadata().
> >>> 
> >>> But it so because there is no way to put our metadata type into
> >>> RelMetadataQuery without changes in Calcite.
> >>> 
> >>> Regards,
> >>> Igor
> >>> 
> >>> чт, 17 окт. 2019 г., 19:16 Xiening Dai :
> >>> 
>  MetadataFactory is still useful. It provides a way to access Metadata
>  directly. If someone creates a new type of Metadata class, it can be
>  accessed through AbstractRelNode.metadata(). This way you don’t need to
>  update RelMetadataQuery interface to include the getter for this new
> >> meta.
>  Although I don’t see this pattern being used often, but I do think it
> >> is
>  still useful and shouldn’t be removed.
>  
>  
>  For your second point, I think you would still need a way to keep
>  RelMetadataQuery object during a rule call. If you choose to create new
>  instance, you will have to pass it around while applying the rule. That
>  actually complicates things a lot.
>  
>  
> > On Oct 17, 2019, at 12:49 AM, XING JIN 
> >> wrote:
> > 
> > 1. RelMetadataQuery covers the functionality of MetadataFactory, why
>  should
> > we keep/maintain both of them ? shall we just deprecate
> >> MetadataFactory.
>  I
> > see MetadataFactory is rarely used in current code. Also I
> > think MetadataFactory is not good place to offering customized
> >> metadata,
> > which will make user confused for the difference between
> >> RelMetadataQuery
> > and MetadataFactory.
> > 
> >> Customized RelMetadataQuery with code generated meta handler for
> > customized metadata, also can provide convenient way to get metadata.
> > It makes sense for me.
> > 
> > 2. If the natural lifespan of a RelMetadataQuery is a RelOptCall,
> >> shall
>  we
> > deprecate RelOptCluster#getMetadataQuery ? If a user wants to get the
> > metadata but without a RelOptCall, he/she will need to create a new
> > instance of RelMetadataQuery.
> > 
> > Xiening Dai  于2019年10月17日周四 上午2:27写道：
> > 
> 

Calcite-Master - Build # 1391 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #1391)

Status: Still Failing

Check console output at https://builds.apache.org/job/Calcite-Master/1391/ to 
view the results.

Re: Re: [DISCUSSION] Extension of Metadata Query

[Haisheng Yuan]

Sounds like we have reached a consensus, I guess.
Can we create a JIRA to allow users to create their own sub-class of 
RelMetadataQuery?

- Haisheng

--
发件人：Julian Hyde
日　期：2019年10月22日 09:58:34
收件人：dev
主　题：Re: [DISCUSSION] Extension of Metadata Query

Yes, the division of labor between MetadataFactory and RelMetadataQuery is a 
good one, and we should keep them intact. One provides the raw metadata, and 
the other provides a typed interface and transactions/caching.

It might be allowable for a user to create their own sub-class of 
RelMetadataQuery that adds only handler fields and metadata methods, provided 
that it follows the existing pattern. We could add a new thread-local in 
RelMetadataQuery.instance() that is a factory to create the required sub-class 
of RelMetadataQuery.

The process by which metadata factories re-generate themselves is delicate and 
subtle:

 public Double getMaxRowCount(RelNode rel) {
 for (;;) {
 try {
 return maxRowCountHandler.getMaxRowCount(rel, this);
 } catch (JaninoRelMetadataProvider.NoHandler e) {
 maxRowCountHandler =
 revise(e.relClass, BuiltInMetadata.MaxRowCount.DEF);
 }
 }
 }

(Note that “revise” generates a new class, creating bytecode via janino, and 
the generated code throws “NoHandler" when it needs to extend itself.) I don’t 
trust the typical Calcite user to be able to write a sub-class that works 
correctly and efficiently.

Julian



> On Oct 18, 2019, at 3:55 AM, XING JIN  wrote:
> 
> +1 on Danny's comment.
> If we use MedataFactory to customize and use RelMetadataQuery for
> convenience, that will make user confused.
> 
> Danny Chan  于2019年10月18日周五 下午12:33写道：
> 
>> That is the point, we should supply a way to extend the RelMetadataQuery
>> conveniently for Calcite, because in most of the RelOptRules, user would
>> use the code like:
>> 
>> RelOptRuleCall.getMetadataQuery
>> 
>> To get a RMQ instead of using AbstractRelNode.metadata() to fetch a
>> MedataFactory.
>> 
>> We should at lest unity the metadata query entrance/interfaces, or it
>> would confuse a lot.
>> 
>> Best,
>> Danny Chan
>> 在 2019年10月18日 +0800 AM12:23，Seliverstov Igor ，写道：
>>> At least in our project (Apache Ignite) we use
>> AbstractRelNode.metadata().
>>> 
>>> But it so because there is no way to put our metadata type into
>>> RelMetadataQuery without changes in Calcite.
>>> 
>>> Regards,
>>> Igor
>>> 
>>> чт, 17 окт. 2019 г., 19:16 Xiening Dai :
>>> 
 MetadataFactory is still useful. It provides a way to access Metadata
 directly. If someone creates a new type of Metadata class, it can be
 accessed through AbstractRelNode.metadata(). This way you don’t need to
 update RelMetadataQuery interface to include the getter for this new
>> meta.
 Although I don’t see this pattern being used often, but I do think it
>> is
 still useful and shouldn’t be removed.
 
 
 For your second point, I think you would still need a way to keep
 RelMetadataQuery object during a rule call. If you choose to create new
 instance, you will have to pass it around while applying the rule. That
 actually complicates things a lot.
 
 
> On Oct 17, 2019, at 12:49 AM, XING JIN 
>> wrote:
> 
> 1. RelMetadataQuery covers the functionality of MetadataFactory, why
 should
> we keep/maintain both of them ? shall we just deprecate
>> MetadataFactory.
 I
> see MetadataFactory is rarely used in current code. Also I
> think MetadataFactory is not good place to offering customized
>> metadata,
> which will make user confused for the difference between
>> RelMetadataQuery
> and MetadataFactory.
> 
>> Customized RelMetadataQuery with code generated meta handler for
> customized metadata, also can provide convenient way to get metadata.
> It makes sense for me.
> 
> 2. If the natural lifespan of a RelMetadataQuery is a RelOptCall,
>> shall
 we
> deprecate RelOptCluster#getMetadataQuery ? If a user wants to get the
> metadata but without a RelOptCall, he/she will need to create a new
> instance of RelMetadataQuery.
> 
> Xiening Dai  于2019年10月17日周四 上午2:27写道：
> 
>> I have seen both patterns in current code base. In most places, for
>> example SubQueryRemoveRule, AggregateUnionTrasposeRule
>> SortJoinTransposeRule, etc., RelOptCluster.getMetadataQuery() is
>> used.
 And
>> there are a few other places where new RelMetadataQuery instance is
>> created, which Haisheng attempts to fix.
>> 
>> Currently RelOptCluster.invalidateMetadataQuery() is called at the
>> end
 of
>> RelOptRuleCall.transformTo(). So the lifespan of RelMetadataQuery
>> is
>> guaranteed to be within a RelOptCall. I think Haisheng’s fix is
>> safe.
>> 
>> 
>>> On Oct 16, 2019, at 1:53 AM, Danny Chan 
>> wrote:
>>> 
>>> This is the reason I was struggling for the discussion.
>>> 
>>> 

Calcite-Master - Build # 1390 - Still Failing

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #1390)

Status: Still Failing

Check console output at https://builds.apache.org/job/Calcite-Master/1390/ to 
view the results.

Calcite-Master - Build # 1389 - Failure

[Apache Jenkins Server]

The Apache Jenkins build system has built Calcite-Master (build #1389)

Status: Failure

Check console output at https://builds.apache.org/job/Calcite-Master/1389/ to 
view the results.

[jira] [Created] (CALCITE-3445) In web site, automatically redirect http to https

[Julian Hyde (Jira)]

Julian Hyde created CALCITE-3445:


 Summary: In web site, automatically redirect http to https
 Key: CALCITE-3445
 URL: https://issues.apache.org/jira/browse/CALCITE-3445
 Project: Calcite
  Issue Type: Bug
  Components: site
Reporter: Julian Hyde
 Fix For: 1.22.0


In web site, automatically redirect http to https.

Per [email thread 'Redirecting to 
https'|https://lists.apache.org/thread.html/3a76df309d01eddacd6abcb47cdd036f32718a5c1f28c7226547c872@%3Cdev.calcite.apache.org%3E],
 the solution is to add an {{.htaccess}} file.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Redirecting to https

[Julian Hyde]

Thanks for the suggestions. I’ve logged 
https://issues.apache.org/jira/browse/CALCITE-3445 
. I’ll try to get to it, 
but feel free to jump in.

> On Oct 23, 2019, at 6:26 PM, Michael Mior  wrote:
> 
> Great! Seems like we could just take lines 1-15 and change beam to
> calcite and we would be set. Glad to see this discussion brought up
> and I think we should make this change.
> --
> Michael Mior
> mm...@apache.org
> 
> Le mer. 23 oct. 2019 à 18:45, Francis Chuang
>  a écrit :
>> 
>> I think we can do this using a .htaccess file (all ASF sites run on the
>> Apache HTTPD).
>> 
>> See Cordova's change to do this:
>> https://github.com/apache/cordova-docs/commit/fcfd9ffafca5547f6859a0bd662db6341b15da34
>> 
>> And Beam's:
>> https://github.com/apache/beam/blob/master/website/src/.htaccess#L12
>> 
>> On 24/10/2019 9:38 am, Julian Hyde wrote:
>>> When you go to http://calcite.apache.org it does not automatically
>>> redirect to https://calcite.apache.org.
>>> 
>>> Does anyone know how we would accomplish this?
>>> 
>>> I notice that http://beam.apache.org does the right thing.
>>> 
>>> Julian
>>> 

[jira] [Created] (CALCITE-3444) Upgrade SQLLine to 1.9.0, and solve "Class path contains multiple SLF4J bindings" problem

[Julian Hyde (Jira)]

Julian Hyde created CALCITE-3444:


 Summary: Upgrade SQLLine to 1.9.0, and solve "Class path contains 
multiple SLF4J bindings" problem
 Key: CALCITE-3444
 URL: https://issues.apache.org/jira/browse/CALCITE-3444
 Project: Calcite
  Issue Type: Bug
Reporter: Julian Hyde


The "Class path contains multiple SLF4J bindings" is as follows:
{noformat}
sqlline version 1.9.0
sqlline> !connect jdbc:hsqldb:res:scott SCOTT TIGER
SLF4J: Class path contains multiple SLF4J bindings.
SLF4J: Found binding in 
[jar:file:/Users/julianhyde/.m2/repository/org/slf4j/slf4j-log4j12/1.7.25/slf4j-log4j12-1.7.25.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: Found binding in 
[jar:file:/Users/julianhyde/.m2/repository/ch/qos/logback/logback-classic/1.1.3/logback-classic-1.1.3.jar!/org/slf4j/impl/StaticLoggerBinder.class]
SLF4J: See http://www.slf4j.org/codes.html#multiple_bindings for an explanation.
SLF4J: Actual binding is of type [org.slf4j.impl.Log4jLoggerFactory]
0: jdbc:hsqldb:res:scott> {noformat}

Calcite's {{sqlline}} script generates {{target/fullclasspath.txt}} with both 
of the above jar files on it. The solution is to remove one of them. I propose 
to remove {{slf4j-log4j12}} from the generated classpath.

Windows uses a different technique (copying dependencies to each module's 
target/dependencies directory). This change does not fix Windows.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (CALCITE-3443) Doesn't parse PreparedStatement successfully for there is placeholders in select area

[huaicui (Jira)]

huaicui created CALCITE-3443:


 Summary: Doesn't parse PreparedStatement successfully for there is 
placeholders in select area
 Key: CALCITE-3443
 URL: https://issues.apache.org/jira/browse/CALCITE-3443
 Project: Calcite
  Issue Type: Bug
  Components: avatica
Affects Versions: 1.21.0
 Environment: linux, mac
Reporter: huaicui


Calcite isn't able to parse the sql that there is a placeholder in select area, 
like this:

{
 "sql":"SELECT TIMESTAMPDIFF(day, CAST('2019-01-01' AS DATE), CAST(? AS 
DATE))>0 as sent",
 "params":[
 {
 "className":"java.lang.String",
 "value":"2019-09-02"
 }
 ]
}

We have a scenario that need to set palceholder in select area, please help to 
fix that;



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: Nested data handling in Caclite

[Igor Guzenko]

Hello Naveen,

1. If I understand correctly, then yes you can extract nested fields from
struct type. The syntax depends on StructKind value for your data type,
for example for FULLY_QUALIFIED struct you should first
make alias for your table and then request nested field like,
table_alias.struct_column.nested_field. In rel tree such expressions are
presented as RexCall with SqlItemOperator operator.
2. Yes, this ability was implemented in CALCITE-3138 [1]. It builds call to
ROW type constructor function on top of flattened tree for necessary
columns.
3. Yes, examples of such functions are ROW(...), ANY_VALUE(...) etc.

In current implementation of flattener  invocation of ROW constructor
function is done despite of null handling same issue exists for some
aggregate function flattening, like COUNT(struct_column).
Proper null handling is real pain for flattener, original idea was to
handle special null indicator for each flattened struct, but in practice I
recognized that it's really hard to deal with flattened fields indices when
related methods are called from very different points, so for now the
problem remains unsolved.
If you can't avoid dealing with null values in your struct columns you
could try to avoid invocation to SqlToRelConverter.flattenTypes(...) and
check whether final plan acceptable for you. As far as I know
there is no reading material for given topic, you can investigate source
code by debugging RelStructuredTypeFlattener and reading some related plans
in SqlToRelConverterTest.java and SqlToRelConverterTest.xml.

[1] https://issues.apache.org/jira/browse/CALCITE-3138

Thanks,
Igor

On Thu, Oct 24, 2019 at 12:57 PM Naveen Kumar
 wrote:

> Hi,
>
> I work at Flipkart, we are using Calcite in our streaming platform. In most
> of our use cases, input data is nested. I understand Calcite flattens
> structs in scan and references fields positionally.
>
> I had a few questions on handling nested data -
>
>1. Can RelNode DAG work with nested data (instead of flattened fields)
>by referencing fields through their nested structure eg,
> data.order.orderId
>2. In the current flattened behavior, can output of a query be a struct.
>Eg if *orderId, orderData.timestamp, orderData.category* are output of
>select query, can I declaratively organise output to below json
> structure -
>   1.
>
>
>
>
>
> *{ "orderId": "order1", "orderData": { "timestamp": 1571904384814,
>  "category": "shoes" } }*
>   3. Can output of a UDF be struct type
>
> Please point me to any reading material or example that would help with
> these questions.
>
> Regards,
> Naveen
>
> --
>
>
>
>
> *-*
>
>
> *This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error, please notify the
> system manager. This message contains confidential information and is
> intended only for the individual named. If you are not the named
> addressee,
> you should not disseminate, distribute or copy this email. Please notify
> the sender immediately by email if you have received this email by mistake
> and delete this email from your system. If you are not the intended
> recipient, you are notified that disclosing, copying, distributing or
> taking any action in reliance on the contents of this information is
> strictly prohibited.*
>
>  
>
> *Any views or opinions presented in this
> email are solely those of the author and do not necessarily represent
> those
> of the organization. Any information on shares, debentures or similar
> instruments, recommended product pricing, valuations and the like are for
> information purposes only. It is not meant to be an instruction or
> recommendation, as the case may be, to buy or to sell securities,
> products,
> services nor an offer to buy or sell securities, products or services
> unless specifically stated to be so on behalf of the Flipkart group.
> Employees of the Flipkart group of companies are expressly required not to
> make defamatory statements and not to infringe or authorise any
> infringement of copyright or any other legal right by email
> communications.
> Any such communication is contrary to organizational policy and outside
> the
> scope of the employment of the individual concerned. The organization will
> not accept any liability in respect of such communication, and the
> employee
> responsible will be personally liable for any damages or other liability
> arising.*
>
>  
>
> *Our organization accepts no liability for the
> content of this email, or for the consequences of any actions taken on the
> basis of the information *provided,* unless that information is
> subsequently confirmed in writing. If you are not the intended recipient,
> you are notified that disclosing, copying, distributing or taking any
> 

Nested data handling in Caclite

[Naveen Kumar]

Hi,

I work at Flipkart, we are using Calcite in our streaming platform. In most
of our use cases, input data is nested. I understand Calcite flattens
structs in scan and references fields positionally.

I had a few questions on handling nested data -

   1. Can RelNode DAG work with nested data (instead of flattened fields)
   by referencing fields through their nested structure eg, data.order.orderId
   2. In the current flattened behavior, can output of a query be a struct.
   Eg if *orderId, orderData.timestamp, orderData.category* are output of
   select query, can I declaratively organise output to below json structure -
  1.





*{ "orderId": "order1", "orderData": { "timestamp": 1571904384814,
 "category": "shoes" } }*
  3. Can output of a UDF be struct type

Please point me to any reading material or example that would help with
these questions.

Regards,
Naveen

-- 



*-*


*This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you have received this email in error, please notify the 
system manager. This message contains confidential information and is 
intended only for the individual named. If you are not the named addressee, 
you should not disseminate, distribute or copy this email. Please notify 
the sender immediately by email if you have received this email by mistake 
and delete this email from your system. If you are not the intended 
recipient, you are notified that disclosing, copying, distributing or 
taking any action in reliance on the contents of this information is 
strictly prohibited.*

 

*Any views or opinions presented in this 
email are solely those of the author and do not necessarily represent those 
of the organization. Any information on shares, debentures or similar 
instruments, recommended product pricing, valuations and the like are for 
information purposes only. It is not meant to be an instruction or 
recommendation, as the case may be, to buy or to sell securities, products, 
services nor an offer to buy or sell securities, products or services 
unless specifically stated to be so on behalf of the Flipkart group. 
Employees of the Flipkart group of companies are expressly required not to 
make defamatory statements and not to infringe or authorise any 
infringement of copyright or any other legal right by email communications. 
Any such communication is contrary to organizational policy and outside the 
scope of the employment of the individual concerned. The organization will 
not accept any liability in respect of such communication, and the employee 
responsible will be personally liable for any damages or other liability 
arising.*

 

*Our organization accepts no liability for the 
content of this email, or for the consequences of any actions taken on the 
basis of the information *provided,* unless that information is 
subsequently confirmed in writing. If you are not the intended recipient, 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.*


_-_

Re: [DISCUSS] State of the project 2019

[XING JIN]

Thanks a lot for your work Francis and +1 for Stamatis to be the next PMC
chair ~ ~

Calcite is a great project and it offers as a strong SQL engine to help
users to build data systems.
My group uses Calcite to accelerate SQLs from multiple data engines by
heuristic based, cost based and materialization based optimization.
As a developer, I really benefit a lot from Calcite and the help from this
great community.

Calcite is not well known ? Yes, it might be less heard by the end users
(who focus on data analysis), but most of data engine developers (AFAIK)
know that Calcite is always a good choice when they
want to build a strong SQL engine for their data systems. This is the charm
of Calcite.

Finally, I agree with Muhammad Gelbana to strenghten documentation for
Calcite.

Best,
Jin

Alessandro Solimando  于2019年10月24日周四
下午4:41写道：

> Hello,
> I have the impression too that Calcite is lesser known than other Apache
> projects, but this is not that surprising to me given the nature of the
> project itself, which requires in-depth knowledge of a rather complex
> topic, which makes it is less prone to a casual use and plug adoption.
> But IMO this is a point of strength and not a weakness, and it's what makes
> Calcite so fascinating! This been said, spreading the word never hurts.
>
> I also agree that the community is much more active now than in the past
> two years, the effort has always been high but now there are more people
> involved, which makes it easier.
>
> On my side I mostly follow the "high-level" discussions more than the
> individual tickets. Such discussions are constructive, pleasant to read and
> instructive.
>
> A big plus also for the high-quality research articles directly stemming
> from the efforts of this community.
>
> Last but not least, Stamatis would make a great PMC chair!
>
> I take the chance to thank you all for the great deal of effort in keeping
> the project alive at such high standards.
>
> Best regards,
> Alessandro
>
>
>
> On Wed, 23 Oct 2019 at 17:00, Ruben Q L  wrote:
>
> > Hello everyone,
> >
> > First of all, thanks for your work, Francis.
> >
> > While I am relatively new in this community I must admit that I totally
> > agree with Danny Chan when he says that we had some *"interesting
> > discussions on the mailing list and we did have some valuable
> > conclusion(like the Join expression rework, the trait sets propagation,
> the
> > metadata etc.)"*. I think we must continue in this direction and keep on
> > our good work together.
> >
> > Apart from that, I agree with Muhammad Gelbana too: ideally we could have
> > more technical documentation of the main modules; but I am also aware
> that
> > it can be very time consuming to generate such documentation, and also to
> > maintain it, and we could easily have out-of-date material on our hands.
> > So, I am not sure how we could proceed.
> > Despite being a great project, I also have the impression that Calcite is
> > not so well-known, and we need to "spread the word" to reach a bigger
> > number of users.
> >
> > I cannot compare with previous years, but I what I have seen so far is a
> > healthy community, with many people collaborating and willing to help
> > beginner (and advanced) users.
> >
> > Finally, I think Stamatis is a great choice for PMC chair :)
> >
> > Best,
> > Ruben Quesada Lopez
> >
> >
> >
> > Le mer. 23 oct. 2019 à 15:09, Michael Mior  a écrit :
> >
> > > Thanks for the summary Francis and +1 for Stamatis as the next PMC
> chair
> > :)
> > >
> > > --
> > > Michael Mior
> > > mm...@apache.org
> > >
> > > Le mer. 23 oct. 2019 à 02:36, Stamatis Zampetakis 
> a
> > > écrit :
> > > >
> > > > It's been a great year so far. Thanks for your great work Francis,
> you
> > > did
> > > > an excellent job!
> > > >
> > > > I also like a lot the way that the mailing list works and the fact
> that
> > > we
> > > > are very active. Apart from helping each other it also centralizes a
> > lot
> > > of
> > > > information, where people may find an answer to their problem quite
> > > easily.
> > > > When I first started to learn about Calcite, the list and the
> archives
> > > were
> > > > indispensable.
> > > >
> > > > It is also very positive that we don't encounter very often
> regressions
> > > > (and most of those encountered were minor), which shows that the
> > quality
> > > > standards of the project are really high and reviewers are really
> > paying
> > > > attention on what is going in. I believe a lot in the motto of
> quality
> > > over
> > > > quantity.
> > > >
> > > > Although we are managing PRs a bit better than the previous years, we
> > > have
> > > > to improve more. I had in my mind that if people assigned to
> themselves
> > > the
> > > > review of the JIRA/PR the feeling of responsibility would make things
> > > > advance faster. I tried applying this to myself but it didn't really
> > work
> > > > much better since there is certainly a lack of time. Other than lack
> of
> > > > time 

Re: [DISCUSS] State of the project 2019

[Alessandro Solimando]

Hello,
I have the impression too that Calcite is lesser known than other Apache
projects, but this is not that surprising to me given the nature of the
project itself, which requires in-depth knowledge of a rather complex
topic, which makes it is less prone to a casual use and plug adoption.
But IMO this is a point of strength and not a weakness, and it's what makes
Calcite so fascinating! This been said, spreading the word never hurts.

I also agree that the community is much more active now than in the past
two years, the effort has always been high but now there are more people
involved, which makes it easier.

On my side I mostly follow the "high-level" discussions more than the
individual tickets. Such discussions are constructive, pleasant to read and
instructive.

A big plus also for the high-quality research articles directly stemming
from the efforts of this community.

Last but not least, Stamatis would make a great PMC chair!

I take the chance to thank you all for the great deal of effort in keeping
the project alive at such high standards.

Best regards,
Alessandro



On Wed, 23 Oct 2019 at 17:00, Ruben Q L  wrote:

> Hello everyone,
>
> First of all, thanks for your work, Francis.
>
> While I am relatively new in this community I must admit that I totally
> agree with Danny Chan when he says that we had some *"interesting
> discussions on the mailing list and we did have some valuable
> conclusion(like the Join expression rework, the trait sets propagation, the
> metadata etc.)"*. I think we must continue in this direction and keep on
> our good work together.
>
> Apart from that, I agree with Muhammad Gelbana too: ideally we could have
> more technical documentation of the main modules; but I am also aware that
> it can be very time consuming to generate such documentation, and also to
> maintain it, and we could easily have out-of-date material on our hands.
> So, I am not sure how we could proceed.
> Despite being a great project, I also have the impression that Calcite is
> not so well-known, and we need to "spread the word" to reach a bigger
> number of users.
>
> I cannot compare with previous years, but I what I have seen so far is a
> healthy community, with many people collaborating and willing to help
> beginner (and advanced) users.
>
> Finally, I think Stamatis is a great choice for PMC chair :)
>
> Best,
> Ruben Quesada Lopez
>
>
>
> Le mer. 23 oct. 2019 à 15:09, Michael Mior  a écrit :
>
> > Thanks for the summary Francis and +1 for Stamatis as the next PMC chair
> :)
> >
> > --
> > Michael Mior
> > mm...@apache.org
> >
> > Le mer. 23 oct. 2019 à 02:36, Stamatis Zampetakis  a
> > écrit :
> > >
> > > It's been a great year so far. Thanks for your great work Francis, you
> > did
> > > an excellent job!
> > >
> > > I also like a lot the way that the mailing list works and the fact that
> > we
> > > are very active. Apart from helping each other it also centralizes a
> lot
> > of
> > > information, where people may find an answer to their problem quite
> > easily.
> > > When I first started to learn about Calcite, the list and the archives
> > were
> > > indispensable.
> > >
> > > It is also very positive that we don't encounter very often regressions
> > > (and most of those encountered were minor), which shows that the
> quality
> > > standards of the project are really high and reviewers are really
> paying
> > > attention on what is going in. I believe a lot in the motto of quality
> > over
> > > quantity.
> > >
> > > Although we are managing PRs a bit better than the previous years, we
> > have
> > > to improve more. I had in my mind that if people assigned to themselves
> > the
> > > review of the JIRA/PR the feeling of responsibility would make things
> > > advance faster. I tried applying this to myself but it didn't really
> work
> > > much better since there is certainly a lack of time. Other than lack of
> > > time sometimes it is our diligence that makes PRs wait a long time till
> > > they get merged. Given that we have a version control system (and at
> any
> > > time we can go back in time) we should be more confident about
> committing
> > > things faster.
> > >
> > > Calcite is a great project that could be used in many different ways by
> > > many people. Unfortunately, I think we are losing many users simply
> > because
> > > they are not aware that such a project exists. At least in Europe,
> > academic
> > > people and as a result university students, graduates, and future
> > engineers
> > > do not know that Calcite exists. I gave a talk last year in a
> university
> > in
> > > France, and nobody in the audience had ever heard of Calcite before. I
> > > think such introductory talks in universities should be done more
> often.
> > > The talks about Calcite in conferences is of course a great way to
> spread
> > > the word; thanks to everybody who got involved in them and keep it up.
> > >
> > > Thanks a lot for the nomination for PMC chair! I will be honoured 

[jira] [Created] (CALCITE-3442) Set `stored_fields = _none` prohibit `FetchPhase` get be involved and improve the Performance for Elasticsearch

[yunfeng (Jira)]

yunfeng created CALCITE-3442:


 Summary: Set `stored_fields = _none` prohibit `FetchPhase` get be 
involved and improve the Performance for Elasticsearch
 Key: CALCITE-3442
 URL: https://issues.apache.org/jira/browse/CALCITE-3442
 Project: Calcite
  Issue Type: Improvement
  Components: elasticsearch-adapter
Reporter: yunfeng
 Fix For: next


 For elasticsearch-adapte,   when  ElasticsearchAggregat involved , set _source 
= false and size = 0 , Elasticsearch `FetchPhase` would still be executed 
against the current  search process and visit the Lucene stored_fields, which 
would lead to performance declined dramatically.  
We can set `stored_fields = _none` prohibit this such behavior completely



--
This message was sent by Atlassian Jira
(v8.3.4#803005)