Introduction and picking an issue

2021-12-20 Thread Abhishek Dasgupta
Hi Calcite Devs!
  I am currently working with Calcite and I am fascinated by the myriad of
cool things one can do with it. I would like to contribute to Calcite and
dig more into it. I am specifically looking at the jiras that are labeled
with the 'newbie' tag and I am thinking of picking Calcite-2901

.
The status shows it is still open and the comment mentioned by Mr.
Statmatis Zampetakis looks apt. Can I create a PR for this change ? or
another issue if this one is not available?

Thanks,
Abhishek.


[jira] [Created] (CALCITE-4863) Incorrect translation of INTERVAL value when fractional part is microsecond.

2021-10-21 Thread Abhishek Dasgupta (Jira)
Abhishek Dasgupta created CALCITE-4863:
--

 Summary: Incorrect translation of INTERVAL value when fractional 
part is microsecond.
 Key: CALCITE-4863
 URL: https://issues.apache.org/jira/browse/CALCITE-4863
 Project: Calcite
  Issue Type: Bug
  Components: core
Reporter: Abhishek Dasgupta


I added the following scenario in testLiteral() unit test present in 
RelToSqlConverterTest.
{code:java}
checkLiteral("INTERVAL '0.01' SECOND");{code}
This scenario failed with the following expected and acutal translation:

EXPECTED:
{code:java}
SELECT *
FROM (VALUES (INTERVAL '0.01' SECOND)) AS t (EXPR$0)
{code}
 

ACTUAL:
{code:java}
SELECT *
FROM (VALUES (INTERVAL '0' SECOND)) AS t (EXPR$0){code}
 

i.e when the code falls in evaluateIntervalLiteralAsSecond() in 
SqlIntervalQualifier, the interval value gets normalized to only the 
millisecond part.

 
{code:java}
private static BigDecimal normalizeSecondFraction(String secondFracStr) {
 // Decimal value can be more than 3 digits. So just get
 // the millisecond part.
 return new BigDecimal("0." + secondFracStr).multiply(THOUSAND);
 }{code}
 
for this particular scenario, sceondFraction part becomes the following after 
exceuting the above code.
{code:java}
secFraction = 0.001000{code}
and then returns an int array of \{sign, year, month, day, hour, second, 
millisecond}, where
{code:java}
millisecond.intVal() = 0{code}
 

 

 My questions are:
 #  Is this is a bug or is it as expected ?
 #  If it is as expected then is it because of [CALCITE-1690] Calcite timestamp 
literals cannot express precision above millisecond, TIMESTAMP(3). As a results 
calcite always delegates to for 
{code:java}
SqlParserUtils.intervalToMillis() // for INTERVAL_SECOND{code}

 ## can we also create something like  
{code:java}
SqlParserUtils.intervalToMicro(){code}
which first gets a int[] ret array of size 7 including microsecond part.
 ##  has the same logic like 
{code:java}
 long l = 0;
 long[] conv = new long[6];
 conv[5] = 1 // microsecond
 conv[4] = conv[5] * 1000; // millisecond
 conv[3] = conv[4] * 1000; // second
 conv[2] = conv[3] * 60; // minute
 conv[1] = conv[2] * 60; // hour
 conv[0] = conv[1] * 24; // day
 for (int i = 1; i < ret.length; i++) {
 l += conv[i - 1] * ret[i];
 }
 return ret[0] * l;{code}

 



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


Apache Calicte learning curve

2020-08-11 Thread Abhishek Dasgupta
Hi Team,
I am working as a Software Developer in data migration sector. We use the
Apache-Calcite framework. I am trying to learn how to use it and apparently
it has a steep learning curve. I went through the documentation but as a
beginner it is difficult to grasp. Can you provide me some useful links
where to start learning Apache Calcite apart from the documentation. Can
you provide a chronological order  what to understand first i.e a step by
step list.

Thanks,
Abhishek Dasgupta