Hi, I prefer Response 1.
When users query some paths that do not exist, it means there are logical errors and we'd better reject the request to let users fix it. -- Jialin Qiao School of Software, Tsinghua University 乔嘉林 清华大学 软件学院 > -----原始邮件----- > 发件人: suyue <[email protected]> > 发送时间: 2019-10-08 20:54:59 (星期二) > 收件人: [email protected] > 抄送: > 主题: Re: [DISCUSS] (IOTDB-240) query problem for iotdb filter > > Hi, all. > > I tried to make the following queries in MySQL：(There is a ‘projectID' > column in the 'CONFIG' table but no xx column.) > select projectID, xx from CONFIG; > Then, I got :[Code: 1054, SQL State: 42S22] Unknown column 'xx' in 'field > list’ > > So, I prefer to report errors directly when there are non-existent columns in > the query statement, which is Response 1. > > > > > > > 在 2019年10月8日，下午7:14，Lei Rui <[email protected]> 写道： > > > > Hi all, > > I want to have more discussions on the responses of selecting non-existent > > timeseries. > > Let's focus on the condition 2 - "select ZT1,ZT31 from root.demo" where > > root.demo.ZT1 doesn't exist. > > There can be 3 responses as follows. > > Response 1: reject service and return an error message. > > Response 2: provide service by neglecting "ZT1" and directly return the > > result table of "select ZT31 from root.demo". > > Response 3: provide service by returning the result table with fields under > > the column "root.demo.ZT1" being null. > > From my side, I definitely disapprove response 3 because of the possible > > confusion raised about the schema. > > My question is which one do you prefer, response 1 or response 2? > > I myself prefer response 2 to response 1, because response 2 not only > > conveys clearly the message that "root.demo.ZT1" doesn't exist, but also > > returns existent data. > > Sincerely, > > Lei Rui > > > > > > On 9/26/2019 14:52，南京大学软件学院薛恺丰<[email protected]> wrote： > > Hi~ I'm working on this issue and I think "both condition 2 and 3 should > > respond with error message" is better > > > > > > > > > > ------------------ 原始邮件 ------------------ > > 发件人: "Yuan Tian (Jira)"<[email protected]>; > > 发送时间: 2019年9月25日(星期三) 晚上9:56 > > 收件人: "dev"<[email protected]>; > > > > 主题: [jira] [Created] (IOTDB-240) query problem for iotdb filter > > > > > > > > EJTTianyu created IOTDB-240: > > ------------------------------- > > > > Summary: query problem for iotdb filter > > Key: IOTDB-240 > > URL: https://issues.apache.org/jira/browse/IOTDB-240 > > Project: Apache IoTDB > > Issue Type: Bug > > Reporter: EJTTianyu > > > > > > When querying a timeseries that does not exist, iotdb shows different > > behavior for SQL with or without filter. > > After starting a new iotdb instance, The following steps in iotdb-client > > below could reproduce the problem. > > Step 1: set storage group to root.demo > > Step 2: CREATE TIMESERIES root.demo.ZT31 WITH DATATYPE=INT64, ENCODING=RLE > > Step 3:insert into root.demo(timestamp,ZT31) values(1,1) > > when using sql: > > 1.select ZT1 from root.demo > > iotdb-client responds with message "Msg: Execute statement error: do not > > select any existing series" > > 2.select ZT1,ZT31 from root.demo > > iotdb-client responds with > > +-----------------------------------+--------------+ > > | Time|root.demo.ZT31| > > +-----------------------------------+--------------+ > > | 1970-01-01T08:00:00.001+08:00| 1| > > +-----------------------------------+--------------+ > > 3.select ZT1,ZT31 from root.demo where ZT1>0 > > iotdb-client responds with message "Msg: Execute statement error: Index: 0, > > Size: 0" > > > > Timeseries ZT1 does not exist in condition 2 and condition 3. However, > > without using ZT1 as filter to query multiple sensors(at least one > > exists), iotdb could respond with datapoints. When using ZT1 as filter, the > > returned msg confused users. > > > > In my opinion, both condition 2 and 3 should respond with message "Msg: > > Execute statement error: do not select any existing series". Or condition 2 > > responds with datapoints, condition 3 responds with "Msg: Execute statement > > error: do not select any existing series". > > > > > > > > > > -- > > This message was sent by Atlassian Jira > > (v8.3.4#803005) >
