Hi Marko, I think the use case you provided is valuable, I need to take a time to consider about how to support that better.
By the way, can you tell me what `IRIs` is and what the Path looks like? If so, I can record it on the PR's explanation to let the PR more meaningful. Best, ----------------------------------- Xiangdong Huang School of Software, Tsinghua University 黄向东 清华大学 软件学院 Marko Friedemann <marko@friedemann.email> 于2019年3月8日周五 下午10:37写道： > Hey, > > Xiangdong Huang <saint...@gmail.com> wrote: > > > So, it is important for IoTDB to recognize which is the measurement name > > from a path. @Marko, that is why I said add a dot in the measurement will > > cause many modifications. > > Right, I can only speak from a limited testing experience, where dots in > device and measurement IDs did not cause any issue (apart from the query, > obviously). > > Specifically, I wrote a test with just the Java-API where I > a) create a tsfile with data points that use IRIs for device and > measurement > b) query the tsfile for subsets of the data via file.query(queryExpression) > > The latter is where I ran into the problem of the path components being > modified according to the described issue. > I went and added a Path subclass that uses reflection to set both private > fields (device and measurement) and the query works just fine. > > > (Maybe not to many... we just need to let users claim which part of a > path > > is a measurement name, and record it on disk, rather than just split the > > path with a dot symbol and use the last substring). > > Well, maybe you could think about supporting backticks or quotes for the > user to indicate leave-alone parts of the query? Something like > select `measurement.id.with.dot` from root.*.`device.id.with.dot`? > > > Anyway, for the API, I would just suggest to rethink the concat-then-split > approach for the two-argument constructor (that would be in the assumption > the > user knows what he's doing). > > Thanks, > Best Regards, > M. >
