Re: [tsfile] [tsquery] path for device/measurement with dots

[Marko Friedemann <ma...@friedemann.email>]

Hey,

Xiangdong Huang <sa...@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.

Re: [tsfile] [tsquery] path for device/measurement with dots

[Marko Friedemann <ma...@friedemann.email>]

Hey,

Xiangdong Huang <sa...@gmail.com> wrote:

> I think the use case you provided is valuable, I need to take a time to
> consider about how to support that better.

Sure, thanks for looking into it.

> 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.

IRIs (Internationalized Resource Identifier) are a generalization of URIs,
see https://www.w3.org/TR/rdf11-concepts/#section-IRIs.

We'd like to express device/measurement in terms of RDF subject/property
(IRIs, eg. "http://example.org/unit23" and "http://example.org/sensor42",
maybe even something like "http://example.org/vocab#forceSensor").

Regards,
M.

Re: [tsfile] [tsquery] path for device/measurement with dots

[Xiangdong Huang <sa...@gmail.com>]

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 <ma...@friedemann.email> 于2019年3月8日周五 下午10:37写道：

> Hey,
>
> Xiangdong Huang <sa...@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.
>