how should I parse out ShowSeriesRow.Key

[TheColonel2688]

I would like to get a list of all of the series in a measurement with a given tag.

Tag being "Department" (haven't gotten that far yet)

So I have gotten here so far.

    var results = await _client.ShowSeriesAsync(_databaseName, MeasurementName);

    var result = results.Series[0];

    foreach (Vibrant.InfluxDB.Client.Rows.ShowSeriesRow row in result.Rows)
    {

    }

And the first row.Key I get is "IsRunning,Department=Test\\ Department,Line=Test\\ Line\\ 1,MAC=00-D0-C9-FC-A9-BA,Name=Press"

Which translated into human is Measurement = "IsRunning" Tag "Department" = "Test Department" Tag "Line" = "Test Line 1" Tag "MAC" = "00-D0-C9-FC-A9-BA" Tag "Name" = "Press"

Do you have a recommendation? It's not JSON. I can probably do some string manipulation and make it json. Can I access the InfluxDB.Client internal deserializer? So I can utilize influxdb.client attributes in POCO classes?

Edit:

If you want after I figure out how to do this I can make a pull request and make this a built-in feature. (Though I have never actually made a pull request before)

[MikaelGRA]

There is currently no deserializer in this library that is capable of deserializing this type of string.

I was not actually aware that influxdb returned the key values like this (including escape characters), but when you think a bit about it, it probably makes sense.

The problem here is that when writing data point using the line protocol, the following characters: ' ', ',' and '=' for tag keys, tag values and field keys must be escaped with a '\'.

Like the following row from one of the (slightly modified) unit tests:

set1Measurement,host=super\ book,region=west-eu cpu=0.708608796684355,ram=1855750652i 1262307664000000000

Here's a reference to the escaping required for the line protocol: https://docs.influxdata.com/influxdb/v1.7/write_protocols/line_protocol_reference/#special-characters

It would probably be fairly easy to make a parser that is capable of parsing such a string though. But it would have to make sure it handles the unescaping.

It would probably useful to have a parser like this as a utility function in this library, so I would be very interested in a PR if you make it. Essentially the function would probably take in a string like this and return a new class representing the measurement name + combination of tags.

[TheColonel2688]

I've already written a utility method with a generic return type today that works, and yes it was pretty simple. The current version just removes all \ from the string, and then formats it as json and deserializes it. So I will have to improve it to allow for actual escape character behavior.

So you would want a utility method so that the user can choose to parse the string or not?

Would there ever be a reason to return an InfluxResultSet?

I was thinking more about just having a syntax like this List<UserPocoType> listOfSeries = _client.ShowSeriesAsync<UserPocoType>(databaseName, measurementName);

I would prefer that for everything that won't ever have more than one result set.

[TheColonel2688]

On a side Note: what is the correct usage for the ShowSeriesAsync() with the string whereoverload? what format should the string take? If there is documentation for it I apologize. So far I haven't found any.

[MikaelGRA]

I'm not big on modifying the result of the ShowSeriesAsync methods because that would be an immediate breaking change for the existing API (theoretically requiring another major version bump).

However it could be a new method that is capable of using the utility method and return a better type.

Essentially most of the methods that are being used on the client are extension methods.

Here's the SHOW SERIES methods:

https://github.com/MikaelGRA/InfluxDB.Client/blob/master/src/Vibrant.InfluxDB.Client/InfluxClientExtensions.cs#L540

[TheColonel2688]

That makes sense. I'm trying to get my current project wrapped up. Hopefully, I can work on this next weekend (not this weekend).

[TheColonel2688]

Am I interpreting the Influx documentation correctly?

\ is parsed as \ \\ is parsed as \ \\\ is parsed as \\ \\\\ is parsed as \\ \\\\\ is parsed as \\\\ \\\\\\ is parsed as \\\\

\ -> \ \<space> -> <space> \\<space> -> \<space> \\\<space> -> \\<space> \"\<space> -> "<space> \\"\<space> -> \"<space> \\\"\<space>\ -> \\"<space>\ \\\"\<space>\\ -> \\"<space>\

\<space><space> would be invalid? \<space>\<space> -> <space><space> \== would be invalid in a name (field, tag measurement etc) but if name was example= then example\= = 'some value' would be valid? \=\= -> ==

or am I miss understanding?

[MikaelGRA]

I think the escape character only escapes the immediately following character. That's what my current implementation is based on.

That would mean that something like \\\ -> \\ is not correct.