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.
