apache / iotdb

Apache IoTDB

Home Page:https://iotdb.apache.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

[Bug] Query error, An error occured within the plugin

SeanGaluzzi opened this issue · comments

Search before asking

  • I searched in the issues and found nothing similar.

Version

IoTDB 1.2.2 Standalone
IoTDB Grafana Plugin 1.0 (Grafana interface)
Grafana 10.2.2

Describe the bug and provide the minimal reproduce step

Problem Description

When executing a SELECT LAST_VALUE(*) align by device query using grafana IoTDB plugin the query return an error. While the IoTDB CLI returns the expected and accurate results

Grafana Explore Query

Grafana_Query_Blurred

also tried without the * on the SELECT Statement:

Grafana_Query_AvoidingStar

IoTDB Cli

IoTDB_Query_Blurried

What did you expect to see?

Expected Behavior

The same table that IoTDB Cli return using the same syntax:

IoTDB_Query_Blurried

What did you see instead?

Actual Behavior

Using this syntax on Grafana with the IoTDB plugin return "Query error, An error occured within the plugin"

Anything else?

Also tried using DISTINCT Statment but nothing changed

The blurried part of the path are just for obscure sensitive data.

Are you willing to submit a PR?

  • I'm willing to submit a PR!

Hi, Grafana Plugin doesn't support aggregate with align by device due to the ResultSet missing time column. It is not a bug.

image
you can see it

@HTHou I've come across some queries that function well using the "align by device" method with both the LAST_VALUE and DISTINCT IoTDB functions.

DISTINCT FUNCTION

DISTINCT

and it also returns a timestamp

immagine (9)

LAST_VALUE FUNCTION

LAST_VALUE

image

I suspect that Grafana appends a dummy timestamp (1970-01-01 01:00:00) to compensate for the fact that IoTDB doesn't always return a timestamp. However, as shown before some times it returns an error which is really difficult to debug without a proper message. In my opinion, this inconsistency is a bug since the functionality should ideally work consistently, either every time or never. It might be worth investigating further to ensure reliable behavior.

any updates?