Re: Do we have a plan to release the first normal version of IoTDB this month?

I think that's a good idea, I think I might start pre-reviewing the current state ... No need in listing findings after a RC. Chris Outlook f??r Android herunterladen From: Julian Feinauer Sent: Friday, March 8, 2019 8:03:46 AM To: dev@i

AW: Do we have a plan to release the first normal version of IoTDB this month?

Hi, I think a (first apache) release is a good idea. Especially to allow people to play around with the artifacts. After what I have seen the code quality is good and the main functionality works well. Julian Urspr??ngliche Nachricht Betreff: Re: Do we have a plan to releas

Re: Do we have a plan to release the first normal version of IoTDB this month?

I think we should try to do a release. At least a preview version. 3 months are not short time for a new project. Of source, no rush, just when you think it is ready and make sense. Sheng Wu Apache SkyWalking, ShardingSphere, Zipkin From Wu Sheng 's phone. -- Original ---

Do we have a plan to release the first normal version of IoTDB this month?

Hi, Over the last three months, we have improved IoTDB in several ways, such as code quality, document and read/write performance. So should we release a normal version to our users since we don’t have a normal version right now. Thanks XuYi

Re: Operation and robustness of iotDB

> (We need to have a merge sort when querying more than one measurement) Users do not need to care about that, because IoTDB/TsFile APIs have merge-sorted the data for users. --- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Xiangdong H

Re: Operation and robustness of iotDB

Hi, Yes, every Chunk has its timestamp column. We design like this because different sensor may have different frequency.. For example, the rotate speed of an engine may be collected 100 per second, while the GPS info is collected every 1 second. And, their start time may be not aligned... So, if

Re: Some personal advice when creating a pull request

Hey, this is a very good idea (especially for large features). When one looks at the mailing list the project seems tob e really low pacing. But when looking at git there are really many people involved and a lot of coding going on. So I totally agree with Xu Yi.. write to the list and get your

Re: Operation and robustness of iotDB

Hey Xu Yi, thanks fort he information. I checked the code and indeed I was wrong. Every Chunk also stores its timestamp. So when I read values through a Query all timestamps are "interpolated" or merged together from all sensors, or? Julian Am 07.03.19, 18:48 schrieb "Xu yi" : Hi,

Some personal advice when creating a pull request

Hi, Recently, I have noticed that some of our committers work hard to improve our system. However, they did the job silently, code a lot, create a pull request and finally merged in to master after reviewed by one or two other guys. I would suggest you can write an email to briefly describe you

Re: AW: Operation and robustness of iotDB

Hi, In my opinion, different measurements use their own timestamp even though they are grouped into one chunk group.they don’t share from each other. What do you think of this @xiangdong Thanks XuYi iPhoneから送信 2019/03/08 1:41、Julian Feinauer のメール: > Hi, > > Yes this is what I meant. > >

AW: Operation and robustness of iotDB

Hi, Yes this is what I meant. Julian Von meinem Mobiltelefon gesendet Ursprüngliche Nachricht Betreff: Re: Operation and robustness of iotDB Von: 徐毅 An: dev@iotdb.apache.org Cc: Hi, In the definition of ChunkGroup, what is the meaning of 'share one time signal'? Do these me

Re: Operation and robustness of iotDB

Hi, In the definition of ChunkGroup, what is the meaning of 'share one time signal'? Do these measurements share same timestamps? Thanks XuYi On 3/8/2019 01:11，Julian Feinauer wrote： Hey Xiangdong, hey all, I like the documentation much. The only thing I'm a bit unsure is about the names (as th

Re: Operation and robustness of iotDB

Hey Xiangdong, hey all, I like the documentation much. The only thing I'm a bit unsure is about the names (as there is no clarification). So, before I update it with any wrong information I would like to ensure that I have the correct understanding. I assume that most naming is similar to Parqu

Re: [DISCUSS] Send Jira Emails to the dev@ list

Done ... Should however take a while till it's updated. Chris Am 07.03.19, 10:16 schrieb "Xiangdong Huang" : Hi Chris, Now we have no issues mailing list. I think dev mailing list is fine for now, maybe we can create the issues@ when the community is larger. By the wa

Re: [tsfile] [query] path for device.measurement that contain dots

Hi Xiangdong, thanks for the clarification, indeed, then I was wrong. In the light of that, I'm unsure whether I like the idea to allow dots for the names or if these should keep forbidden. This makes it (visibily) clear what part is the measurement and what is the "path". Julian Am 07.03.19,

Re: [DISCUSS] Send Jira Emails to the dev@ list

Hi Chris, Now we have no issues mailing list. I think dev mailing list is fine for now, maybe we can create the issues@ when the community is larger. By the way, revi...@iotdb.apache.org is not shown on http://incubator.apache.org/projects/iotdb.html. An update is needed. Best, -

Re: [tsfile] [query] path for device.measurement that contain dots

Hi, @Julian I think we support what you want now.. for example, you can create 3 timeseries by: ``` set storage group to root.sg1; create timeseries root.sg1.location1.deviceType1.deviceID.m1 with datatype=FLOAT, encoding=RLE; create timeseries root.sg1.location1.deviceType2.deviceID.m1 with data

Re: [DISCUSS] Send Jira Emails to the dev@ list

Hi all, To be a little more concrete ... we send the create to both dev@ and issues@ And I really like it. Chris Am 07.03.19, 08:53 schrieb "Julian Feinauer" : Hi all, I just noticed, that currently there is no notification or so for Jira Issues to the dev@ list. Just recentl

Re: [tsfile] [query] path for device.measurement that contain dots

Hi Xiangdong, what do you think of a subtile generalization of the current "device" approach. If we would allow dots in the name, we could the possibility to create "trees" like its done e.g. for akka actors [1] or MQTT Topics [2]. What I mean is that one could add more information in the "path"