[jira] [Created] (CALCITE-2489) Order of fields in JavaTypeFactoryImpl#createStructType is unstable

2018-08-27 Thread Vladimir Sitnikov (JIRA) 
Vladimir Sitnikov created CALCITE-2489:
--

 Summary: Order of fields in JavaTypeFactoryImpl#createStructType 
is unstable
 Key: CALCITE-2489
 URL: https://issues.apache.org/jira/browse/CALCITE-2489
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.17.0
Reporter: Vladimir Sitnikov
Assignee: Julian Hyde


{{JavaTypeFactoryImpl#createStructType}} relies on 
{{java.lang.Class#getFields}} to get public fields, however it does not sort 
elements.

That might produce confusing results since Calcite relies on field order.
That might result in flaky tests as well (as execution plans rely on field 
order).

There are other {{#getFields}} usages.
For instance: {{org.apache.calcite.rel.type.RelDataTypeFactoryImpl#fieldsOf}}, 
{{org.apache.calcite.interpreter.TableScanNode#createQueryable}}, etc.

It looks like we should implement Calcite-specific sort of the fields, and 
avoid adding new usages {{getFields}} to Calcite code.

For instance:
a) We might want to sort the fields from the super class to derived class. That 
is derived fields should come after the fields of a base class.
b) When annotation is missing, we might want to sort fields on field 
names/field types (so the order is consistent)
c) Add field-level annotation {{@CalciteField(int order)}}
d) We might want to exclude certain fields by flagging with annotation as well 
(e.g. {{@CalciteField(exclude=true)}}

Note: {{a}} and {{b}} are enough to get consistent field order.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Calcite-Master - Build # 796 - Still Failing

2018-08-27 Thread Apache Jenkins Server 
The Apache Jenkins build system has built Calcite-Master (build #796)

Status: Still Failing

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

Re: Giving the Calcite logo some love

2018-08-27 Thread Michael Mior 
I personally quite like the second one of these although I believe I prefer
the text from the previous logo. That said, of everything I've seen Daniel
sent so far, I think any of them would be a big improvement that I'd be
happy with :)

--
Michael Mior
mm...@apache.org



Le lun. 27 août 2018 à 16:00, Daniel Gruno  a écrit :

> On 08/27/2018 09:04 PM, Julian Hyde wrote:
> > Everyone, please be sure to cc Daniel when you reply to this thread. (He
> is making the same offer to a lot of projects and understandably he does
> not want to subscribe to all of their dev lists.)
>
> Indeed :D
>
> I had another idea thrown at me, with refraction and primary colors as
> an idea, and this is the output:
> http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposal2.svg
> (it's got a few versions to look at). Perhaps that is more to the spirit
> of the project?
>
> With regards,
> Daniel.
>
> >
> >> On Aug 27, 2018, at 5:37 AM, Michael Mior  wrote:
> >>
> >> Definitely agreed that the logo could use some love. I like what you've
> >> done with the type in the logo and I also like Julian's suggestion of
> >> refraction. I'll see what I can do over the next couple days about
> >> combining those two things.
> >>
> >> --
> >> Michael Mior
> >> mm...@apache.org
> >>
> >>
> >>
> >> Le dim. 26 août 2018 à 16:56, Daniel Gruno  a
> écrit :
> >>
> >>> Hello, awesome Calcite people!
> >>>
> >>> As some of you may know, I'm on an arduous mission of gathering and
> >>> touching up all logos we have at Apache. During this task, I realized
> >>> the calcite logo has some flaws that does not make it super fit for
> >>> print, so perhaps it's time to look for a new logo?
> >>>
> >>> I did a quick proposal, figuring "calcite...minerals...mining!" - if
> I'm
> >>> completely off track, let me know :D Anyway, the proposal is at:
> >>>
> >>>
> http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposed.svg
> >>>
> >>> (current logo is found at
> >>> http://www.apache.org/logos/comdev-test/#calcite for reference)
> >>>
> >>> If you like it, it's hereby ALv2 so feel free to use it.
> >>> If you want changes, or maybe a logo contest, that's also a-okay! Just
> >>> let me know if you have feedback, and remember to CC me if so, as I'm
> >>> not on this mailing list.
> >>>
> >>> With warm regards,
> >>> Daniel.
> >>>
> >
>
>

Re: Giving the Calcite logo some love

2018-08-27 Thread Vladimir Sitnikov 
Daniel, I like what you do, and I wonder if you could reduce the level of
fine details (number of colours, number of fine lines) in the logos.
calcite-proposed.svg definitely looks better than the current logo.
proposal2 is somewhat comparable to the current logo (since proposal2 uses
colors and/or fine lines, and it makes logo barely recognizable at the
small scale).

I wonder if we could depict something around
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSqqD3dy8BmMeEUJQaeOYTp_4Bdvq-2Xz_EXCqIXVMQjmfK5QJbSA
or
https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcSEqCuAxcDMtlvCKEiGftOSxZq-3dNN7knuOHerpj39g2IIYqdg

I mean to end up in a couple of simple graphical primitives.

PS. I wish I could draw.

Vladimir

Re: Giving the Calcite logo some love

2018-08-27 Thread Edmon Begoli 
I like this second version.

On Mon, Aug 27, 2018 at 4:00 PM Daniel Gruno  wrote:

> On 08/27/2018 09:04 PM, Julian Hyde wrote:
> > Everyone, please be sure to cc Daniel when you reply to this thread. (He
> is making the same offer to a lot of projects and understandably he does
> not want to subscribe to all of their dev lists.)
>
> Indeed :D
>
> I had another idea thrown at me, with refraction and primary colors as
> an idea, and this is the output:
> http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposal2.svg
> (it's got a few versions to look at). Perhaps that is more to the spirit
> of the project?
>
> With regards,
> Daniel.
>
> >
> >> On Aug 27, 2018, at 5:37 AM, Michael Mior  wrote:
> >>
> >> Definitely agreed that the logo could use some love. I like what you've
> >> done with the type in the logo and I also like Julian's suggestion of
> >> refraction. I'll see what I can do over the next couple days about
> >> combining those two things.
> >>
> >> --
> >> Michael Mior
> >> mm...@apache.org
> >>
> >>
> >>
> >> Le dim. 26 août 2018 à 16:56, Daniel Gruno  a
> écrit :
> >>
> >>> Hello, awesome Calcite people!
> >>>
> >>> As some of you may know, I'm on an arduous mission of gathering and
> >>> touching up all logos we have at Apache. During this task, I realized
> >>> the calcite logo has some flaws that does not make it super fit for
> >>> print, so perhaps it's time to look for a new logo?
> >>>
> >>> I did a quick proposal, figuring "calcite...minerals...mining!" - if
> I'm
> >>> completely off track, let me know :D Anyway, the proposal is at:
> >>>
> >>>
> http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposed.svg
> >>>
> >>> (current logo is found at
> >>> http://www.apache.org/logos/comdev-test/#calcite for reference)
> >>>
> >>> If you like it, it's hereby ALv2 so feel free to use it.
> >>> If you want changes, or maybe a logo contest, that's also a-okay! Just
> >>> let me know if you have feedback, and remember to CC me if so, as I'm
> >>> not on this mailing list.
> >>>
> >>> With warm regards,
> >>> Daniel.
> >>>
> >
>
>

[jira] [Created] (CALCITE-2490) Wrong results when grouping set is repeated

2018-08-27 Thread Vladimir Sitnikov (JIRA) 
Vladimir Sitnikov created CALCITE-2490:
--

 Summary: Wrong results when grouping set is repeated
 Key: CALCITE-2490
 URL: https://issues.apache.org/jira/browse/CALCITE-2490
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.17.0
Reporter: Vladimir Sitnikov
Assignee: Julian Hyde


The following query produces 2 rows in PostgreSQL and just one in Calcite
{code:sql}select count(*) from (select * from (values(1)) as t(a)) group by 
grouping sets ((a),(a)){code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Giving the Calcite logo some love

2018-08-27 Thread Julian Hyde 
Everyone, please be sure to cc Daniel when you reply to this thread. (He is 
making the same offer to a lot of projects and understandably he does not want 
to subscribe to all of their dev lists.)

> On Aug 27, 2018, at 5:37 AM, Michael Mior  wrote:
> 
> Definitely agreed that the logo could use some love. I like what you've
> done with the type in the logo and I also like Julian's suggestion of
> refraction. I'll see what I can do over the next couple days about
> combining those two things.
> 
> --
> Michael Mior
> mm...@apache.org
> 
> 
> 
> Le dim. 26 août 2018 à 16:56, Daniel Gruno  a écrit :
> 
>> Hello, awesome Calcite people!
>> 
>> As some of you may know, I'm on an arduous mission of gathering and
>> touching up all logos we have at Apache. During this task, I realized
>> the calcite logo has some flaws that does not make it super fit for
>> print, so perhaps it's time to look for a new logo?
>> 
>> I did a quick proposal, figuring "calcite...minerals...mining!" - if I'm
>> completely off track, let me know :D Anyway, the proposal is at:
>> 
>> http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposed.svg
>> 
>> (current logo is found at
>> http://www.apache.org/logos/comdev-test/#calcite for reference)
>> 
>> If you like it, it's hereby ALv2 so feel free to use it.
>> If you want changes, or maybe a logo contest, that's also a-okay! Just
>> let me know if you have feedback, and remember to CC me if so, as I'm
>> not on this mailing list.
>> 
>> With warm regards,
>> Daniel.
>>

Re: Giving the Calcite logo some love

2018-08-27 Thread Daniel Gruno 

On 08/27/2018 09:04 PM, Julian Hyde wrote:

Everyone, please be sure to cc Daniel when you reply to this thread. (He is 
making the same offer to a lot of projects and understandably he does not want 
to subscribe to all of their dev lists.)


Indeed :D

I had another idea thrown at me, with refraction and primary colors as 
an idea, and this is the output: 
http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposal2.svg 
(it's got a few versions to look at). Perhaps that is more to the spirit 
of the project?


With regards,
Daniel.




On Aug 27, 2018, at 5:37 AM, Michael Mior  wrote:

Definitely agreed that the logo could use some love. I like what you've
done with the type in the logo and I also like Julian's suggestion of
refraction. I'll see what I can do over the next couple days about
combining those two things.

--
Michael Mior
mm...@apache.org



Le dim. 26 août 2018 à 16:56, Daniel Gruno  a écrit :


Hello, awesome Calcite people!

As some of you may know, I'm on an arduous mission of gathering and
touching up all logos we have at Apache. During this task, I realized
the calcite logo has some flaws that does not make it super fit for
print, so perhaps it's time to look for a new logo?

I did a quick proposal, figuring "calcite...minerals...mining!" - if I'm
completely off track, let me know :D Anyway, the proposal is at:

http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposed.svg

(current logo is found at
http://www.apache.org/logos/comdev-test/#calcite for reference)

If you like it, it's hereby ALv2 so feel free to use it.
If you want changes, or maybe a logo contest, that's also a-okay! Just
let me know if you have feedback, and remember to CC me if so, as I'm
not on this mailing list.

With warm regards,
Daniel.

[jira] [Created] (CALCITE-2491) Simplify NameSet, NameMap, NameMultimap implementation

2018-08-27 Thread Vladimir Sitnikov (JIRA) 
Vladimir Sitnikov created CALCITE-2491:
--

 Summary: Simplify NameSet, NameMap, NameMultimap implementation
 Key: CALCITE-2491
 URL: https://issues.apache.org/jira/browse/CALCITE-2491
 Project: Calcite
  Issue Type: Bug
  Components: core
Affects Versions: 1.17.0
Reporter: Vladimir Sitnikov
Assignee: Julian Hyde
 Fix For: 1.18.0


{code:java}  @Test public void lowerCaseWithLowerCode() {
for (int i = 0; i < 0x; i++) {
  char c = (char) i;
  if (!Character.isLetter(c)) {
continue;
  }

  char lc = Character.toLowerCase(c);
  char uc = Character.toUpperCase(c);
  if (lc < uc) {
System.out.println(c + ": (" + ((int) lc) + ") " + lc + " < " + uc + " 
(" + ((int) uc) + ")");
  }
}
  }
{code}

{noformat}
µ: (181) µ < Μ (924)
ÿ: (255) ÿ < Ÿ (376)
İ: (105) i < İ (304)
Ÿ: (255) ÿ < Ÿ (376)
ƀ: (384) ƀ < Ƀ (579)
ƕ: (405) ƕ < Ƕ (502)
ƚ: (410) ƚ < Ƚ (573)
ƞ: (414) ƞ < Ƞ (544)
ƿ: (447) ƿ < Ƿ (503)
Ƕ: (405) ƕ < Ƕ (502)
Ƿ: (447) ƿ < Ƿ (503)
Ƞ: (414) ƞ < Ƞ (544)
Ƚ: (410) ƚ < Ƚ (573)
ȿ: (575) ȿ < Ȿ (11390)
ɀ: (576) ɀ < Ɀ (11391)
Ƀ: (384) ƀ < Ƀ (579)
ɐ: (592) ɐ < Ɐ (11375)
ɑ: (593) ɑ < Ɑ (11373)
ɒ: (594) ɒ < Ɒ (11376)
ɜ: (604) ɜ < Ɜ (42923)
ɡ: (609) ɡ < Ɡ (42924)
ɥ: (613) ɥ < Ɥ (42893)
ɦ: (614) ɦ < Ɦ (42922)
ɪ: (618) ɪ < Ɪ (42926)
ɫ: (619) ɫ < Ɫ (11362)
ɬ: (620) ɬ < Ɬ (42925)
ɱ: (625) ɱ < Ɱ (11374)
ɽ: (637) ɽ < Ɽ (11364)
ʇ: (647) ʇ < Ʇ (42929)
ʝ: (669) ʝ < Ʝ (42930)
ʞ: (670) ʞ < Ʞ (42928)
ͻ: (891) ͻ < Ͻ (1021)
ͼ: (892) ͼ < Ͼ (1022)
ͽ: (893) ͽ < Ͽ (1023)
ϲ: (1010) ϲ < Ϲ (1017)
ϴ: (952) θ < ϴ (1012)
Ϲ: (1010) ϲ < Ϲ (1017)
Ͻ: (891) ͻ < Ͻ (1021)
Ͼ: (892) ͼ < Ͼ (1022)
Ͽ: (893) ͽ < Ͽ (1023)
ᲈ: (7304) ᲈ < Ꙋ (42570)
ᵹ: (7545) ᵹ < Ᵹ (42877)
ᵽ: (7549) ᵽ < Ᵽ (11363)
ẞ: (223) ß < ẞ (7838)
ἀ: (7936) ἀ < Ἀ (7944)
ἁ: (7937) ἁ < Ἁ (7945)
ἂ: (7938) ἂ < Ἂ (7946)
ἃ: (7939) ἃ < Ἃ (7947)
ἄ: (7940) ἄ < Ἄ (7948)
ἅ: (7941) ἅ < Ἅ (7949)
ἆ: (7942) ἆ < Ἆ (7950)
ἇ: (7943) ἇ < Ἇ (7951)
Ἀ: (7936) ἀ < Ἀ (7944)
Ἁ: (7937) ἁ < Ἁ (7945)
Ἂ: (7938) ἂ < Ἂ (7946)
Ἃ: (7939) ἃ < Ἃ (7947)
Ἄ: (7940) ἄ < Ἄ (7948)
Ἅ: (7941) ἅ < Ἅ (7949)
Ἆ: (7942) ἆ < Ἆ (7950)
Ἇ: (7943) ἇ < Ἇ (7951)
ἐ: (7952) ἐ < Ἐ (7960)
ἑ: (7953) ἑ < Ἑ (7961)
ἒ: (7954) ἒ < Ἒ (7962)
ἓ: (7955) ἓ < Ἓ (7963)
ἔ: (7956) ἔ < Ἔ (7964)
ἕ: (7957) ἕ < Ἕ (7965)
Ἐ: (7952) ἐ < Ἐ (7960)
Ἑ: (7953) ἑ < Ἑ (7961)
Ἒ: (7954) ἒ < Ἒ (7962)
Ἓ: (7955) ἓ < Ἓ (7963)
Ἔ: (7956) ἔ < Ἔ (7964)
Ἕ: (7957) ἕ < Ἕ (7965)
ἠ: (7968) ἠ < Ἠ (7976)
ἡ: (7969) ἡ < Ἡ (7977)
ἢ: (7970) ἢ < Ἢ (7978)
ἣ: (7971) ἣ < Ἣ (7979)
ἤ: (7972) ἤ < Ἤ (7980)
ἥ: (7973) ἥ < Ἥ (7981)
ἦ: (7974) ἦ < Ἦ (7982)
ἧ: (7975) ἧ < Ἧ (7983)
Ἠ: (7968) ἠ < Ἠ (7976)
Ἡ: (7969) ἡ < Ἡ (7977)
Ἢ: (7970) ἢ < Ἢ (7978)
Ἣ: (7971) ἣ < Ἣ (7979)
Ἤ: (7972) ἤ < Ἤ (7980)
Ἥ: (7973) ἥ < Ἥ (7981)
Ἦ: (7974) ἦ < Ἦ (7982)
Ἧ: (7975) ἧ < Ἧ (7983)
ἰ: (7984) ἰ < Ἰ (7992)
ἱ: (7985) ἱ < Ἱ (7993)
ἲ: (7986) ἲ < Ἲ (7994)
ἳ: (7987) ἳ < Ἳ (7995)
ἴ: (7988) ἴ < Ἴ (7996)
ἵ: (7989) ἵ < Ἵ (7997)
ἶ: (7990) ἶ < Ἶ (7998)
ἷ: (7991) ἷ < Ἷ (7999)
Ἰ: (7984) ἰ < Ἰ (7992)
Ἱ: (7985) ἱ < Ἱ (7993)
Ἲ: (7986) ἲ < Ἲ (7994)
Ἳ: (7987) ἳ < Ἳ (7995)
Ἴ: (7988) ἴ < Ἴ (7996)
Ἵ: (7989) ἵ < Ἵ (7997)
Ἶ: (7990) ἶ < Ἶ (7998)
Ἷ: (7991) ἷ < Ἷ (7999)
ὀ: (8000) ὀ < Ὀ (8008)
ὁ: (8001) ὁ < Ὁ (8009)
ὂ: (8002) ὂ < Ὂ (8010)
ὃ: (8003) ὃ < Ὃ (8011)
ὄ: (8004) ὄ < Ὄ (8012)
ὅ: (8005) ὅ < Ὅ (8013)
Ὀ: (8000) ὀ < Ὀ (8008)
Ὁ: (8001) ὁ < Ὁ (8009)
Ὂ: (8002) ὂ < Ὂ (8010)
Ὃ: (8003) ὃ < Ὃ (8011)
Ὄ: (8004) ὄ < Ὄ (8012)
Ὅ: (8005) ὅ < Ὅ (8013)
ὑ: (8017) ὑ < Ὑ (8025)
ὓ: (8019) ὓ < Ὓ (8027)
ὕ: (8021) ὕ < Ὕ (8029)
ὗ: (8023) ὗ < Ὗ (8031)
Ὑ: (8017) ὑ < Ὑ (8025)
Ὓ: (8019) ὓ < Ὓ (8027)
Ὕ: (8021) ὕ < Ὕ (8029)
Ὗ: (8023) ὗ < Ὗ (8031)
ὠ: (8032) ὠ < Ὠ (8040)
ὡ: (8033) ὡ < Ὡ (8041)
ὢ: (8034) ὢ < Ὢ (8042)
ὣ: (8035) ὣ < Ὣ (8043)
ὤ: (8036) ὤ < Ὤ (8044)
ὥ: (8037) ὥ < Ὥ (8045)
ὦ: (8038) ὦ < Ὦ (8046)
ὧ: (8039) ὧ < Ὧ (8047)
Ὠ: (8032) ὠ < Ὠ (8040)
Ὡ: (8033) ὡ < Ὡ (8041)
Ὢ: (8034) ὢ < Ὢ (8042)
Ὣ: (8035) ὣ < Ὣ (8043)
Ὤ: (8036) ὤ < Ὤ (8044)
Ὥ: (8037) ὥ < Ὥ (8045)
Ὦ: (8038) ὦ < Ὦ (8046)
Ὧ: (8039) ὧ < Ὧ (8047)
ὰ: (8048) ὰ < Ὰ (8122)
ά: (8049) ά < Ά (8123)
ὲ: (8050) ὲ < Ὲ (8136)
έ: (8051) έ < Έ (8137)
ὴ: (8052) ὴ < Ὴ (8138)
ή: (8053) ή < Ή (8139)
ὶ: (8054) ὶ < Ὶ (8154)
ί: (8055) ί < Ί (8155)
ὸ: (8056) ὸ < Ὸ (8184)
ό: (8057) ό < Ό (8185)
ὺ: (8058) ὺ < Ὺ (8170)
ύ: (8059) ύ < Ύ (8171)
ὼ: (8060) ὼ < Ὼ (8186)
ώ: (8061) ώ < Ώ (8187)
ᾀ: (8064) ᾀ < ᾈ (8072)
ᾁ: (8065) ᾁ < ᾉ (8073)
ᾂ: (8066) ᾂ < ᾊ (8074)
ᾃ: (8067) ᾃ < ᾋ (8075)
ᾄ: (8068) ᾄ < ᾌ (8076)
ᾅ: (8069) ᾅ < ᾍ (8077)
ᾆ: (8070) ᾆ < ᾎ (8078)
ᾇ: (8071) ᾇ < ᾏ (8079)
ᾈ: (8064) ᾀ < ᾈ (8072)
ᾉ: (8065) ᾁ < ᾉ (8073)
ᾊ: (8066) ᾂ < ᾊ (8074)
ᾋ: (8067) ᾃ < ᾋ (8075)
ᾌ: (8068) ᾄ < ᾌ (8076)
ᾍ: (8069) ᾅ < ᾍ (8077)
ᾎ: (8070) ᾆ < ᾎ (8078)
ᾏ: (8071) ᾇ < ᾏ (8079)
ᾐ: (8080) ᾐ < ᾘ (8088)
ᾑ: (8081) ᾑ < ᾙ (8089)
ᾒ: (8082) ᾒ < ᾚ (8090)
ᾓ: (8083) ᾓ < ᾛ (8091)
ᾔ: (8084) ᾔ < ᾜ (8092)
ᾕ: (8085) ᾕ < ᾝ (8093)
ᾖ: (8086) ᾖ < ᾞ (8094)
ᾗ: (8087) ᾗ < ᾟ (8095)
ᾘ: (8080) ᾐ < ᾘ

Re: Giving the Calcite logo some love

2018-08-27 Thread Michael Mior 
Definitely agreed that the logo could use some love. I like what you've
done with the type in the logo and I also like Julian's suggestion of
refraction. I'll see what I can do over the next couple days about
combining those two things.

--
Michael Mior
mm...@apache.org



Le dim. 26 août 2018 à 16:56, Daniel Gruno  a écrit :

> Hello, awesome Calcite people!
>
> As some of you may know, I'm on an arduous mission of gathering and
> touching up all logos we have at Apache. During this task, I realized
> the calcite logo has some flaws that does not make it super fit for
> print, so perhaps it's time to look for a new logo?
>
> I did a quick proposal, figuring "calcite...minerals...mining!" - if I'm
> completely off track, let me know :D Anyway, the proposal is at:
>
> http://www.apache.org/logos/comdev-test/res/calcite/calcite-proposed.svg
>
> (current logo is found at
> http://www.apache.org/logos/comdev-test/#calcite for reference)
>
> If you like it, it's hereby ALv2 so feel free to use it.
> If you want changes, or maybe a logo contest, that's also a-okay! Just
> let me know if you have feedback, and remember to CC me if so, as I'm
> not on this mailing list.
>
> With warm regards,
> Daniel.
>

Re: Assign alias to a column in RelBuilder

2018-08-27 Thread Michael Mior 
Anand,

Just a small request that if the responses others gave resolved your issue,
it would be great if you could post the resolution on your Stack Overflow
question. Thanks!

https://stackoverflow.com/questions/51994631/assign-alias-to-a-column-in-calcite-relbuilder

--
Michael Mior
mm...@apache.org



Le jeu. 23 août 2018 à 17:54, Anand Gupta  a écrit :

> Hi All,
>
> I am using RelBuilder to build relational expression and then converting it
> to a SQL query using Rel2SqlConverter. I skimmed through the examples of
> RelBuilder
> <
> https://github.com/apache/calcite/blob/master/core/src/test/java/org/apache/calcite/examples/RelBuilderExample.java
> >
> but
> couldn't figure out a way to assign an alias to a column name.
>
> I am able to select columns from a table and create a query like
>
> "select col1, col2, col3 from table1"
>
> However, I want to do something like
>
> "select col1 as t1, col2 as t2, col3 as n9 from table1"
>
> Ideally, there should be a way to set an alias while projecting the
> columns. However, I couldn't find it. I found two relevant methods "as" and
> "alias" in the code. However, couldn't make them work - "as" only works on
> table and "alias" refer to table name alias.
>
> Any suggestion on how to make this work will be appreciated.
>
> Thanks,
> -A
>

[jira] [Created] (CALCITE-2492) is there any way to define dynamic parameters for table in query

2018-08-27 Thread Wenlong Lyu (JIRA) 
Wenlong Lyu created CALCITE-2492:


 Summary: is there any way to define dynamic parameters for table 
in query
 Key: CALCITE-2492
 URL: https://issues.apache.org/jira/browse/CALCITE-2492
 Project: Calcite
  Issue Type: New Feature
Reporter: Wenlong Lyu
Assignee: Julian Hyde


Currently we are trying to implement a catalog and sql engine with calcite, 
which need to support define table representing all kinds of storage: message 
queue, db, etc. When try to query a table of message queue from catalog, we 
need to specify the range of data to scan，such like start_time/end_time, which 
is not supported in calcite。
Is there a good way to solve a problem?
Is it good to extend calcite with dynamic parameters like: {{ select * from 
tableName with (start_time='', end_time='') }}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CALCITE-2493) Update avatica-go dependencies

2018-08-27 Thread Francis Chuang (JIRA) 
Francis Chuang created CALCITE-2493:
---

 Summary: Update avatica-go dependencies
 Key: CALCITE-2493
 URL: https://issues.apache.org/jira/browse/CALCITE-2493
 Project: Calcite
  Issue Type: Task
  Components: avatica-go
Reporter: Francis Chuang
Assignee: Francis Chuang


There are updates to the dependencies used by avatica-go. Avatica-go should 
used those updated versions.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

Re: Maven wrapper

2018-08-27 Thread Julian Hyde 
Re-opening a discussion from earlier this year (and logged as 
https://issues.apache.org/jira/browse/CALCITE-2112 
).

I have changed my mind on this issue. I encountered a user today for whom 
getting a valid version of maven was a significant obstacle. I am now +1 — I 
think it would be beneficial to include mvnw and mvnw.bat in the source 
distribution, and use them in our default build instructions.

I do not think it increases complexity. Advanced users can use “mvn” if they 
choose, but the default instructions would mention only “./mvnw”.

We do not need to include maven-wrapper.jar or MavenWrapperDownloader.jar. mvnw 
and mvnw.bat work fine without them. As they make release votes more 
complicated, I think we should exclude these.

There were a mixture or -1, -0 and +1 in the original thread. Has anyone else 
changed position?

Julian


> On Jan 2, 2018, at 5:01 PM, Julian Hyde  wrote:
> 
> We already have a tool that provides a container for the whole build process. 
> That tool is maven. I do not recall a time where someone had problems because 
> they had the wrong version of maven installed; so this is a non-problem.
> 
> I’ve written C/C++ projects before (using autoconf, libtool, mingw etc.), and 
> thank heavens we don’t have their problems.
> 
> If we were to use a wrapper, we’d either have to get the wrapper from an 
> external repo, or we’d have to distribute the wrapper. For the first, we’ve 
> just shifted the version-management problem; for the second, we’d be 
> distributing our own tool-chain, including binaries (non-source files), which 
> is problematic for an open source project. 
> 
> Julian
> 
> 
>> On Jan 2, 2018, at 3:31 PM, Josh Elser  wrote:
>> 
>> +1 to the simplicity.
>> 
>> But, to Vladimir's issues (thx btw), maybe we can solve some of those 
>> pain-points another way? I've seen some projects (notably, those with 
>> compilation of C/C++ code) provide a Dockerfile that can create an 
>> environment capable of building that native code.
>> 
>> It seems like a lot of the things Vladimir cites could be solved by a 
>> similar approach which would keep us on a single build tool (instead, 
>> providing a ready-made environment to build without polluting anything else).
>> 
>> I'd be OK with that approach if someone wanted to make that work.
>> 
>> On 1/2/18 5:03 PM, Julian Hyde wrote:
>>> Yes.
>>> But I claim that adding mvnw to the picture makes things more complicated 
>>> for the typical user, because there are now more options to understand.
>>> Julian
 On Jan 2, 2018, at 2:00 PM, Michael Mior  wrote:
 
 Even if we do include mvnw, isn't it still possible to use a compatible mvn
 directly?
 
 --
 Michael Mior
 mm...@apache.org
 
 2018-01-02 15:35 GMT-05:00 Julian Hyde :
 
> True, but for 2 and 3 it’s not much of a hardship to type
> 
> $ /usr/local/maven-x.y.z/bin/mvn -s my-settings.xml target
> 
> rather than
> 
> $ mvn target
> 
> And for 1, I claim that typing “mvn” is less surprising to most people
> than typing “mvnw”. Because most people who build java code these days are
> familiar with mvn.
> 
> Julian
> 
> 
> 
> 
> 
> 
>> On Jan 2, 2018, at 12:17 PM, Vladimir Sitnikov <
> sitnikov.vladi...@gmail.com> wrote:
>> 
>>> Multiple versions of Maven can be installed side-by-side (and we don't
>> have esoteric requirements). As such, I don't see the need for such a
>> change
>> 
>> The reasons could include:
>> 1) Simplified Apache Maven installation for those who have no experience
>> with it
>> 2) Having multiple settings.xml files (e.g. if corporate rules requires
>> certain settings.xml that is incompatible with Apache Calcite
> settings.xml)
>> 3) Simplified management of multiple Apache Maven versions. In the same
>> way, corporate rules might require specific mvn version (outdated due to
>> plugins, etc), so that version would likely be the default.
>> 
>> Vladimir
> 
> 
>