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" of a device to allow for filtering. Think of the three devices
"location1.deviceType1.deviceId" "location1.deviceType2.deviceId" "location2.deviceType1.deviceId" Then I gould ask for: "all devices from location 1" with "location.* "all devices of type 2" with "%.deviceType2.%" "all devices" with "*" (where * means match multiple "hierarchies" and "%" menas match one hierarchy, a bit how MQTT does it with # and *). I think this would be really cool, to also allow these "device paths" for queries. What do you think? Julian [1] https://doc.akka.io/docs/akka/current/general/addressing.html [2] https://www.hivemq.com/blog/mqtt-essentials-part-5-mqtt-topics-best-practices/ Am 07.03.19, 05:40 schrieb "Xiangdong Huang" <saint...@gmail.com>: Hi, It seems this will cause a big modification... (Change the Path class is easy, but it will lead to a confusion for SQL layer..) A solution is needed to let SQL recognize that. I have created a issue on JIRA: https://issues.apache.org/jira/browse/IOTDB-38 Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Marko Friedemann <marko@friedemann.email> 于2019年3月7日周四 上午4:06写道： > Hey, > > I want to report an issue with tsfile, specifically its query capabilities. > > The two-argument constructor for org.apache.iotdb.tsfile.read.common.Path > that is now available in the apache incubator project still does not allow > proper construction of a path where the measurement name contains dots. > > Specifically, the issue is that the two-argument constructor concatenates > the two arguments with a path-separator character (the dot) and then splits > the result again, using the seperator (the dot), instead of just using the > supplied arguments as they are. > This results in the path components being incorrect (device basically runs > to lastIndexOf('.') for the full path) and the query failing. > > The rest of tsfile's write/read/query functionality doesn't seem to mind > measurement names that contain dots (think RDF and IRIs) and the intended > query can be run with a minor fix by sub-classing the Path class. > (Unfortunately, Path::init() is also private, so the work-around is not > readily possible.) > > Regards, > Marko Friedemann >
