[jira] [Closed] (IOTDB-341) Can not query data from grafana except for float data type

[Tianan Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/IOTDB-341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tianan Li closed IOTDB-341.
---

> Can not query data from grafana except for float data type
> --
>
> Key: IOTDB-341
> URL: https://issues.apache.org/jira/browse/IOTDB-341
> Project: Apache IoTDB
>  Issue Type: Bug
>Reporter: Tianan Li
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> When using grafana, it's unable to show the data correctly unless the type of 
> data is Float. The data will always be 0.



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

[jira] [Created] (IOTDB-341) Can not query data from grafana except for float data type

[Tianan Li (Jira)]

Tianan Li created IOTDB-341:
---

 Summary: Can not query data from grafana except for float data type
 Key: IOTDB-341
 URL: https://issues.apache.org/jira/browse/IOTDB-341
 Project: Apache IoTDB
  Issue Type: Bug
Reporter: Tianan Li


When using grafana, it's unable to show the data correctly unless the type of 
data is Float. The data will always be 0.



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

[jira] [Closed] (IOTDB-337) Can not fetch data correctly when change timestamp precision of engine

[Tianan Li (Jira)]

 [ 
https://issues.apache.org/jira/browse/IOTDB-337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Tianan Li closed IOTDB-337.
---

> Can not fetch data correctly when change timestamp precision of engine
> --
>
> Key: IOTDB-337
> URL: https://issues.apache.org/jira/browse/IOTDB-337
> Project: Apache IoTDB
>  Issue Type: Bug
>Reporter: Tianan Li
>Priority: Major
>  Labels: pull-request-available
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> In the grafana module, timestamps are in milliseconds. In this case, when 
> users choose "us" or "ns" in engine, it'll not work correctly.



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

[jira] [Created] (IOTDB-339) Optimize QueryPlan

[Jialin Qiao (Jira)]

Jialin Qiao created IOTDB-339:
-

 Summary: Optimize QueryPlan
 Key: IOTDB-339
 URL: https://issues.apache.org/jira/browse/IOTDB-339
 Project: Apache IoTDB
  Issue Type: Improvement
Reporter: Jialin Qiao


For a query such as "select s1, s1 from root.d1", the query process is as 
follows:

(1) Parse the SQL to a QueryPlan, in which the selected paths are .

(2) Return the selected paths to the client for result printing, and recording 
this QueryPlan in the server.

(3) When the client fetches the result, the QueryPlan is passed to 
QueryProcessExecutor. The executor deduplicate the paths and execute the plan.

(4) Return the result set.

 

I recommend moving the deduplication to step (1) and put the origin projected 
paths and deduplicated paths in QueryPlan. Then, the executor could focus on 
executing, instead of optimization.

 

 



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

Re: [VOTE] Apache IoTDB (incubating) 0.8.2 RC2 release

[Jialin Qiao]

Hi,

+1 (binding)

The source release:
incubating in name ok
signatures and hashes  ok
DISCLAIMER ok
LICENSE and NOTICE ok
no jar files
./mvnw.sh clean install ok

The binary distribution:
could start in mac, jdk8
statements executed right

Thanks,
--
Jialin Qiao

Xiangdong Huang  于2019年12月3日周二 下午9:26写道：

> Hi all,
>
> Now I open a new vote for Apache IoTDB (incubating) 0.8.2 RC2, which fixes
> issues in RC1.
>
> Apache IoTDB (incubating) 0.8.2 is a bug-fix version from 0.8.1. You can
> get its mainly changes from [5].
>
> Apache IoTDB (Incubating) 0.8.2 has been staged under [2] and it’s time to
> vote
> on accepting it for release.  All Maven artifacts are available under [1].
> If approved we will seek final release approval from the IPMC.
>
> Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1
> are required to pass.
>
> Release tag: release/0.8.2
> Hash for the release tag: 09a94f2c02dec27f483a2ccb41a8265331be193d
>
> Before voting +1 PMC/PPMC members are required to download
> the signed source code package, compile it as provided, and test
> the resulting executable on their own platform, along with also
> verifying that the package meets the requirements of the ASF policy
> on releases.
>
> You can achieve the above by following [4].
>
> [ ]  +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [4])
>
> [ ]  -1 reject (explanation required)
>
>
> [1] https://repository.apache.org/content/repositories/orgapacheiotdb-1021
> [2] https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.2/rc2
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]
>
> https://cwiki.apache.org/confluence/display/IOTDB/Validating+a+staged+Release
> [5]
>
> https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.2/rc2/RELEASE_NOTES.md
>
> Best,
> ---
> Xiangdong Huang
> School of Software, Tsinghua University
>
>  黄向东
> 清华大学 软件学院
>

[jira] [Created] (IOTDB-338) Meet error when disconnecting with the server

[Jialin Qiao (Jira)]

Jialin Qiao created IOTDB-338:
-

 Summary: Meet error when disconnecting with the server
 Key: IOTDB-338
 URL: https://issues.apache.org/jira/browse/IOTDB-338
 Project: Apache IoTDB
  Issue Type: Bug
Affects Versions: 0.9.0
Reporter: Jialin Qiao


The client-thread in server meet error when the client disconnect with server:

 
{code:java}
//代码占位符
09:09:42.140 [pool-2-IoTDB-JDBC-Client-thread-1] ERROR 
org.apache.thrift.server.TThreadPoolServer - Thrift error occurred during 
processing of message.09:09:42.140 [pool-2-IoTDB-JDBC-Client-thread-1] ERROR 
org.apache.thrift.server.TThreadPoolServer - Thrift error occurred during 
processing of message.org.apache.thrift.transport.TTransportException: null at 
org.apache.thrift.transport.TIOStreamTransport.read(TIOStreamTransport.java:132)
 at org.apache.thrift.transport.TTransport.readAll(TTransport.java:86) at 
org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:425) at 
org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:321) at 
org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:225)
 at org.apache.thrift.TBaseProcessor.process(TBaseProcessor.java:27) at 
org.apache.thrift.server.TThreadPoolServer$WorkerProcess.run(TThreadPoolServer.java:310)
 at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) 
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) 
at java.lang.Thread.run(Thread.java:745)
{code}
 



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

Pypi distribution for IoTDB Python Client API

[Xiangdong Huang]

Hi,

I write a setup.py to distribute IoTDB's Python library to PyPi.

Now I just upload it to Test PyPi [1], please have a review to point out
which is needed to modify (according to the guide [2]).

If no more issues, I will submit a PR for the setup.py file and upload the
binary python files to PyPi formally.

Notice: if you want to try the python client example by using [3], you need
to modify Line 26 and 31 from `from rpc.` to `from iotdb.rpc`

[1] https://test.pypi.org/project/apache-iotdb/
[2]
https://cwiki.apache.org/confluence/display/INCUBATOR/DistributionGuidelines
[3]
https://github.com/apache/incubator-iotdb/blob/release%2F0.9.0/client-py/src/client_example.py

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

 黄向东
清华大学 软件学院

[DISCUSS] Apache IoTDB (incubating) 0.8.2 RC2 release

[Xiangdong Huang]

Hi,

If you have any questions about 0.8.2 RC2, please discuss here.

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

 黄向东
清华大学 软件学院

[VOTE] Apache IoTDB (incubating) 0.8.2 RC2 release

[Xiangdong Huang]

Hi all,

Now I open a new vote for Apache IoTDB (incubating) 0.8.2 RC2, which fixes
issues in RC1.

Apache IoTDB (incubating) 0.8.2 is a bug-fix version from 0.8.1. You can
get its mainly changes from [5].

Apache IoTDB (Incubating) 0.8.2 has been staged under [2] and it’s time to
vote
on accepting it for release.  All Maven artifacts are available under [1].
If approved we will seek final release approval from the IPMC.

Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1
are required to pass.

Release tag: release/0.8.2
Hash for the release tag: 09a94f2c02dec27f483a2ccb41a8265331be193d

Before voting +1 PMC/PPMC members are required to download
the signed source code package, compile it as provided, and test
the resulting executable on their own platform, along with also
verifying that the package meets the requirements of the ASF policy
on releases.

You can achieve the above by following [4].

[ ]  +1 accept (indicate what you validated - e.g. performed the non-RM
items in [4])

[ ]  -1 reject (explanation required)


[1] https://repository.apache.org/content/repositories/orgapacheiotdb-1021
[2] https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.2/rc2
[3] https://www.apache.org/dev/release.html#approving-a-release
[4]
https://cwiki.apache.org/confluence/display/IOTDB/Validating+a+staged+Release
[5]
https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.2/rc2/RELEASE_NOTES.md

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

 黄向东
清华大学 软件学院

[jira] [Created] (IOTDB-337) Can not fetch data correctly when change timestamp precision of IoTDB engine

[Tianan Li (Jira)]

Tianan Li created IOTDB-337:
---

 Summary: Can not fetch data correctly when change timestamp 
precision of IoTDB engine
 Key: IOTDB-337
 URL: https://issues.apache.org/jira/browse/IOTDB-337
 Project: Apache IoTDB
  Issue Type: Bug
Reporter: Tianan Li


In the grafana module, timestamps are in milliseconds. In this case, when users 
choose "us" or "ns" in engine, it'll not work correctly.



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

Re:Re: Solving jira problem (IOTDB-298) Refactor the "last" and "first" aggregators

[thss15_yit]

Hi,
I think my problem is only a special example of IOTDB-335, my work will use 
some existing functions to implement a 'last' function we possibly need now, 
but it can't be a general way to solve IOTDB-335, and I also don't know how to 
deal with IOTDB-335 , perhaps others could help.
Yi Tao








At 2019-12-03 15:48:13, "刘大伟" <13965...@qq.com> wrote:
>Hi,
>I'm terribly sorry to bother you,  is this the same problem as 
>IOTDB-335(https://issues.apache.org/jira/browse/IOTDB-335 
>)?
>
>
>
>> 在 2019年12月3日，下午3:37，thss15_yit  写道：
>> 
>> Hi,
>> Now I'm trying to design and develop a new 'last' function to get the 
>> last time-value pairs in one or several timeseries, working on JIRA issue 
>> [IOTDB-298], Now an example of this function is SELECT LAST(d0.s1, d1.s2) 
>> FROM root.sg1 , to get the last value in root.sg1.d0.s1 and root.sg1.d1.s2
>> You can see the function's particular grammar and examples in the 
>> attached file last.md .
>> I'm glad to get your suggestions. Thank you.
>> Tao Yi
>> 
>> 
>> 
>> 
>> 
>> At 2019-11-29 11:30:18, "thss15_yit"  wrote:
>> >Hi,
>> >I have been working on JIRA issue [IOTDB-298], and now in the following 
>> > pull request I change the aggregation function's name from first,last to 
>> > first_value,last_value to make it more clear, and change the relevant 
>> > documents. 
>> >The pull request is https://github.com/apache/incubator-iotdb/pull/594, 
>> >Thanks for your checking.
>> >I'm going to complete a new 'last' function to get the last point(s) on 
>> > this issue. The function still needs to be discussed. Thanks for your idea.
>> >Tao Yi 
>> >
>> >
>> >
>> >
>> > 
>> 
>> 
>>  
>

[jira] [Created] (IOTDB-336) Binary files incompatible between JDK8 and JDK11

[xiangdong Huang (Jira)]

xiangdong Huang created IOTDB-336:
-

 Summary: Binary files incompatible between JDK8 and JDK11
 Key: IOTDB-336
 URL: https://issues.apache.org/jira/browse/IOTDB-336
 Project: Apache IoTDB
  Issue Type: Bug
Reporter: xiangdong Huang


I tried to use JDK11 to compile a binary file, you can get it at 
[https://dist.apache.org/repos/dist/dev/incubator/iotdb/0.8.2/rc1].

However, if a user uses JDK8 to run it, an exception will occur:

java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer;

 

It is because before JDK9, ByteBuffer.clear() returns  Buffer, while from JDK9 
on, the method return ByteBuffer.

 

According to [https://github.com/apache/curator/pull/312], add a parameter 
`–release 8` can solve the problem. 

In maven, we can add a property called 

```

8

```

I am verifying the solution now.

 

 



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

Re: Solving jira problem (IOTDB-298) Refactor the "last" and "first" aggregators

[刘大伟]

Hi,
I'm terribly sorry to bother you,  is this the same problem as 
IOTDB-335(https://issues.apache.org/jira/browse/IOTDB-335 
)?



> 在 2019年12月3日，下午3:37，thss15_yit  写道：
> 
> Hi,
> Now I'm trying to design and develop a new 'last' function to get the 
> last time-value pairs in one or several timeseries, working on JIRA issue 
> [IOTDB-298], Now an example of this function is SELECT LAST(d0.s1, d1.s2) 
> FROM root.sg1 , to get the last value in root.sg1.d0.s1 and root.sg1.d1.s2
> You can see the function's particular grammar and examples in the 
> attached file last.md .
> I'm glad to get your suggestions. Thank you.
> Tao Yi
> 
> 
> 
> 
> 
> At 2019-11-29 11:30:18, "thss15_yit"  wrote:
> >Hi,
> >I have been working on JIRA issue [IOTDB-298], and now in the following 
> > pull request I change the aggregation function's name from first,last to 
> > first_value,last_value to make it more clear, and change the relevant 
> > documents. 
> >The pull request is https://github.com/apache/incubator-iotdb/pull/594, 
> >Thanks for your checking.
> >I'm going to complete a new 'last' function to get the last point(s) on 
> > this issue. The function still needs to be discussed. Thanks for your idea.
> >Tao Yi 
> >
> >
> >
> >
> > 
> 
> 
>  

AW: Avoid packing incorrect files into source-release.zip

[Christofer Dutz]

Hi Xiangdong,

No worries, that's what I'm here for. But let's not call it reading. For me and 
probably all of your mentors reading Chinese documents will stay almost 
impossible. Same for non Chinese committers and ppmc members. I did some 
pattern matching to guess what the document might say.

When basing your core processes on Chinese, you should pay attention to have an 
identical English translation. Everything else ist just not inclusive. And 
makes giving support difficult.

I think you saw some of the sideeffects with all of these failed RCs in the 
past.

Chris

Von: Xiangdong Huang 
Gesendet: Dienstag, 3. Dezember 2019 03:27:20
An: dev@iotdb.apache.org 
Betreff: Re: Avoid packing incorrect files into source-release.zip

Hi Chris,

> And you should guide the RM to the target/checkout/target directory
instead of the target directory.

I think this is what makes the error. I used target/*-source-release.zip*
rather than target/checkout/target/ .

Many thanks, and thanks for reading Chinese documents...

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

 黄向东
清华大学 软件学院


Christofer Dutz  于2019年12月2日周一 下午11:46写道：

> Hi Xiangdong,
>
> I think I know what the general problem is:
> From that page (not much I can actually understand much)
> But it does mention the release:perform step and immediately after that I
> mentions the source and binary distributions.
> Also it mentions validating the source and binaries build by the prepare
> step and does the release perform after that.
>
> You have to execute the perform step and then validate the signatures of
> the artifacts built by that.
>
> So you should move the source and bin distribution validation guilde to
> after the release:perform.
> And you should guide the RM to the target/checkout/target directory
> instead of the target directory.
>
> Chris
>
>
>
> Am 02.12.19, 14:42 schrieb "Xiangdong Huang" :
>
> Hi Chris,
>
> I am sure that I ran `mvn release:perform` after ran `mvn
> release:prepare`.  On page [1], step 3.1 and 3.2 are  `mvn
> release:prepare`
> and `mvn release:perform`
>
> As I am going to generate RC2 of 0.8.2, I can try once again.
>
> [1]
>
> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=130027555
>
> Best,
> ---
> Xiangdong Huang
> School of Software, Tsinghua University
>
>  黄向东
> 清华大学 软件学院
>
>
> Christofer Dutz  于2019年12月2日周一 下午4:59写道：
>
> > Hi Xiangdong,
> >
> > the "mvn release:prepare" step does the following:
> > - Checks if there are uncommitted filed
> > - Updates the version to the release version
> > - Checks if there are remaining SNAPSHOT dependencies
> > - Runs a full build including tests with this version
> > - If this build succeeds, It commits the changes and tags this commit
> > - Then it changes the versions to the next development version
> > - Then it commits this version too
> > - Then it pushes the changes
> >
> > The step you have to do now is run the "mvn release:perform"
> > - Check out the tagged version from git into the main
> "target/checkout"
> > directory
> > - Spawns a "mvn -P apache-release deploy" build in that directory
> > - This builds the source bundle in "target/checkout/target" and
> creates
> > the hashes and signs the artifacts
> > - During the build it also deploys the maven artifacts to the apache
> nexus
> >
> > As soon as that's done, you:
> > - Go to the Apache nexus and close the staging repo
> > - Create a new staged release by uploading the RELEASE_NOTES, README
> and
> > the source bundle together with the hashes and signatures to SVN
> >
> > To me it looks as if you're simply uploading the stuff created in the
> > first step, which is not correct as it isn't
> > executed from a clean checkout and it will contain other stuff
> that's just
> > laying around in your workspace.
> >
> > Chris
> >
> >
> > Am 01.12.19, 15:35 schrieb "Xiangdong Huang" :
> >
> > Hi,
> >
> > > it will checkout the git revision the prepare goal tagged as
> release
> > version. It will checkout this into the target/checkout
> directory.
> > If so, it is quite strange that why there was something
> incorrect in
> > previous releases..
> >
> > Now the command is `mvn release:prepare
> -DautoVersionSubmodules=true`,
> > I am
> > not sure whether it download source code from github first, I
> need to
> > check
> > it when I run release next time..
> >
> > > So I guess you re-ran the release build more than once
> > Yes it may be. Sometime I ran `mvn release:prepare`  and if
> I find
> > failures, I ran `mvn release:rollback` and run
> `relrease:prepare` again
> > after fixing