[jira] [Created] (IOTDB-202) Bug in example module

2019-09-06 Thread Yuan Tian (Jira)
Yuan Tian created IOTDB-202:
---

 Summary: Bug in example module
 Key: IOTDB-202
 URL: https://issues.apache.org/jira/browse/IOTDB-202
 Project: Apache IoTDB
  Issue Type: Bug
Reporter: Yuan Tian
 Attachments: WechatIMG111.png

When I use TsFileWriteWithRowBatch class to write into test.tsfile, both of 
TsFileRead and TsFileSequenceRead work fine. However, while using 
TsFileWriteWithTSRecord to write, TsFileSequenceRead still work well, but 
TsFileRead will crash. After printing some record, it will throw an exception 
as following:

!WechatIMG111.png!

 

 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


Re: [jira] [Created] (IOTDB-202) Bug in example module

2019-09-06 Thread Jialin Qiao
Hi,

This is because the written data type is not compatible with the filter 
constructed in TsFileRead.

I fixed this bug in this PR [1].

[1] https://github.com/apache/incubator-iotdb/pull/378

Best,
--
Jialin Qiao
School of Software, Tsinghua University

乔嘉林
清华大学 软件学院

> -原始邮件-
> 发件人: "Yuan Tian (Jira)" 
> 发送时间: 2019-09-06 15:14:00 (星期五)
> 收件人: dev@iotdb.apache.org
> 抄送: 
> 主题: [jira] [Created] (IOTDB-202) Bug in example module
> 
> Yuan Tian created IOTDB-202:
> ---
> 
>  Summary: Bug in example module
>  Key: IOTDB-202
>  URL: https://issues.apache.org/jira/browse/IOTDB-202
>  Project: Apache IoTDB
>   Issue Type: Bug
> Reporter: Yuan Tian
>  Attachments: WechatIMG111.png
> 
> When I use TsFileWriteWithRowBatch class to write into test.tsfile, both of 
> TsFileRead and TsFileSequenceRead work fine. However, while using 
> TsFileWriteWithTSRecord to write, TsFileSequenceRead still work well, but 
> TsFileRead will crash. After printing some record, it will throw an exception 
> as following:
> 
> !WechatIMG111.png!
> 
>  
> 
>  
> 
> 
> 
> --
> This message was sent by Atlassian Jira
> (v8.3.2#803003)


Re: time series with double datatype insert problem

2019-09-06 Thread Xiangdong Huang
Hi,

I think we can follow what Tian Jiang said to check whether KairosDB
considering it as a Long rather than a Float.

By the way, as Jialin and Julian said, I think it is ok if we print 0.0 for
Float 0.

Best,
---
Xiangdong Huang
School of Software, Tsinghua University

 黄向东
清华大学 软件学院


Tian Jiang  于2019年9月5日周四 上午4:21写道:

> Hi,
>
>
> If I don't get it wrong, KariosDB need not to create schema ahead and
> automatically inferences datatype. So there is a good chance that your `0`
> will be recognized as a long instead of a float.
>
>
> Tian Jiang
>
>
> | |
> Tian Jiang
> |
> |
> jt2594...@163.com
> |
> 签名由网易邮箱大师定制
> On 9/5/2019 16:13,Jialin Qiao wrote:
> Hi,
>
> When I try the following java codes, it always print 0.0.
>
> ```
> float a = 0f;
> System.out.println(a);
> a = 0.0f;
> System.out.println(a);
> double b = 0d;
> System.out.println(b);
> b = 0.0d;
> System.out.println(b);
> ```
>
> I think it is fine to print 0.0 in the IoTDB Client, as long as it is a
> float value (0f). I wonder how could KairosDB print 0...
>
> Best,
> --
> Jialin Qiao
> School of Software, Tsinghua University
>
> 乔嘉林
> 清华大学 软件学院
>
> -原始邮件-
> 发件人: "勾王敏浩" 
> 发送时间: 2019-09-05 15:02:27 (星期四)
> 收件人: dev@iotdb.apache.org
> 抄送:
> 主题: time series with double datatype insert problem
>
> Hi,
> Currently, we find that a time series with  DATATYPE=DOUBLE,
> ENCODING=GORILLA ,when insert a datapoint like (1,0) , it returns (1,0.0).
> While in KairosDB, it returns (1,0). Do we need to modify this?
>
>
> Thank you,
> Wangminhao Gou
>
>


[jira] [Created] (IOTDB-203) A new result set format

2019-09-06 Thread Jialin Qiao (Jira)
Jialin Qiao created IOTDB-203:
-

 Summary: A new result set format
 Key: IOTDB-203
 URL: https://issues.apache.org/jira/browse/IOTDB-203
 Project: Apache IoTDB
  Issue Type: New Feature
Reporter: Jialin Qiao


When executing a SQL like "select d1.s1, d2.s1 from root.sg1", the default 
result set format in IoTDB is 

"time, root.sg1.d1.s1, root.sg1.d2.s1"

1 , 1, 1

2, 2, 2

However, some users want to get another format, The results could be grouped by 
device, then sorted by time.

"time, deviceId, s1".

1, root.sg1.d1, 1

2, root.sg1.d2, 2

 

This can be done in the client, but it would be better if we support this 
format in the server.

 



--
This message was sent by Atlassian Jira
(v8.3.2#803003)


A new result set format

2019-09-06 Thread Jialin Qiao
Hi,

As described in this issue, a new result set format is wanted by users. I'd 
like to open a discussion here.

For simplicity, I refer this format "time, root.sg1.d1.s1, root.sg1.d2.s1" to 
wide table, and "time, deviceId, s1" as narrow table. 

This issue is not only about how to organize the results, but also the query 
process. 

There are some advantages about narrow table.

(1) For wide table, we need to open a SeriesReader for each series at the same 
time, each SeriesReader holds some ChunkMetadatas. For narrow table, we only 
need to open SeriesReaders for one device at one time, then return results and 
open SeriesReaders for the next device, which occupies less memory compared to 
the wide table. 
(2) Avoid reading all series at once may also improve the query latency.

There is also a question:

(1) If we show result in the narrow table format for users, do we need to 
highlight the concept of table and device? 
(2) If the answer of the first question is yes, do we need to support sql: 
"select time, deviceId, s1, s2, s3 from root.sg1 where deviceId=d1"? This may 
involve a lot of work...

From my side, I prefer the answers of the two questions are all NO. Then we do 
not need to change the sql grammar and only use a new query process to organize 
the result set.

Best,
--
Jialin Qiao
School of Software, Tsinghua University

乔嘉林
清华大学 软件学院

> -原始邮件-
> 发件人: "Jialin Qiao (Jira)" 
> 发送时间: 2019-09-07 09:40:00 (星期六)
> 收件人: dev@iotdb.apache.org
> 抄送: 
> 主题: [jira] [Created] (IOTDB-203) A new result set format
> 
> Jialin Qiao created IOTDB-203:
> -
> 
>  Summary: A new result set format
>  Key: IOTDB-203
>  URL: https://issues.apache.org/jira/browse/IOTDB-203
>  Project: Apache IoTDB
>   Issue Type: New Feature
> Reporter: Jialin Qiao
> 
> 
> When executing a SQL like "select d1.s1, d2.s1 from root.sg1", the default 
> result set format in IoTDB is 
> 
> "time, root.sg1.d1.s1, root.sg1.d2.s1"
> 
> 1 , 1, 1
> 
> 2, 2, 2
> 
> However, some users want to get another format, The results could be grouped 
> by device, then sorted by time.
> 
> "time, deviceId, s1".
> 
> 1, root.sg1.d1, 1
> 
> 2, root.sg1.d2, 2
> 
>  
> 
> This can be done in the client, but it would be better if we support this 
> format in the server.
> 
>  
> 
> 
> 
> --
> This message was sent by Atlassian Jira
> (v8.3.2#803003)


Re: A new result set format

2019-09-06 Thread Julian Feinauer
Hi Jialin,

perhaps one question about "wanted by users" means (as I didn’t see anything on 
the list).
How do these users get in contact with you?

Julian

Am 07.09.19, 04:29 schrieb "Jialin Qiao" :

Hi,

As described in this issue, a new result set format is wanted by users. I'd 
like to open a discussion here.

For simplicity, I refer this format "time, root.sg1.d1.s1, root.sg1.d2.s1" 
to wide table, and "time, deviceId, s1" as narrow table. 

This issue is not only about how to organize the results, but also the 
query process. 

There are some advantages about narrow table.

(1) For wide table, we need to open a SeriesReader for each series at the 
same time, each SeriesReader holds some ChunkMetadatas. For narrow table, we 
only need to open SeriesReaders for one device at one time, then return results 
and open SeriesReaders for the next device, which occupies less memory compared 
to the wide table. 
(2) Avoid reading all series at once may also improve the query latency.

There is also a question:

(1) If we show result in the narrow table format for users, do we need to 
highlight the concept of table and device? 
(2) If the answer of the first question is yes, do we need to support sql: 
"select time, deviceId, s1, s2, s3 from root.sg1 where deviceId=d1"? This may 
involve a lot of work...

From my side, I prefer the answers of the two questions are all NO. Then we 
do not need to change the sql grammar and only use a new query process to 
organize the result set.

Best,
--
Jialin Qiao
School of Software, Tsinghua University

乔嘉林
清华大学 软件学院

> -原始邮件-
> 发件人: "Jialin Qiao (Jira)" 
> 发送时间: 2019-09-07 09:40:00 (星期六)
> 收件人: dev@iotdb.apache.org
> 抄送: 
> 主题: [jira] [Created] (IOTDB-203) A new result set format
> 
> Jialin Qiao created IOTDB-203:
> -
> 
>  Summary: A new result set format
>  Key: IOTDB-203
>  URL: https://issues.apache.org/jira/browse/IOTDB-203
>  Project: Apache IoTDB
>   Issue Type: New Feature
> Reporter: Jialin Qiao
> 
> 
> When executing a SQL like "select d1.s1, d2.s1 from root.sg1", the 
default result set format in IoTDB is 
> 
> "time, root.sg1.d1.s1, root.sg1.d2.s1"
> 
> 1 , 1, 1
> 
> 2, 2, 2
> 
> However, some users want to get another format, The results could be 
grouped by device, then sorted by time.
> 
> "time, deviceId, s1".
> 
> 1, root.sg1.d1, 1
> 
> 2, root.sg1.d2, 2
> 
>  
> 
> This can be done in the client, but it would be better if we support this 
format in the server.
> 
>  
> 
> 
> 
> --
> This message was sent by Atlassian Jira
> (v8.3.2#803003)