Tag or annotate query.

[aadrian]

Hi,

Please add the possibility to tag/annotate/mark the queries.

In many cases, the amount of queries is just too big, and it's a problem to identify/find the ones that are important/relevant.
Also queries come from different applications/sources too (and it seems that POWA itself also has some)

Having a user defined tag/annotation on the Query would allow a quick filtering/sorting of those relevant.

Thank you.

[rjuju]

Hi,

How would you see such a feature working? Would you like to manually add tag(s) query by query, and/or be able to display all the graphs with additional filters based on what's already stored (for instance include/exclude some userid).

That being said, the important queries for an optimisation point of view can usually be found quickly by sorting the various grids by a specific metrics, like the queries that generated most temp files, had most execution, had highest cumulated execution time...

[aadrian]

How would you see such a feature working?

Just some simple DB table that links to the query would do it (e.g. powa_statements_tags)
(not even a UI would be needed to add entries in the beginning)

Than join with that table so that the Queries UI Table can display that extra column with that content provided by the user.
With this, the user could easily sort/filter, or just see right away the relevant stuff.

This would also allow that the POWA specific queries to be tagged automatically, e.g. with a "POWA" tag for
#172

Would you like to manually add tag(s) query by query, and/or be able to display all the graphs with additional filters based on what's already stored (for instance include/exclude some userid).

That would be of course very cool, but would require too much development I suppose :) .

[rjuju]

We're in the middle of a major UI rewrite (see powa-team/powa-web#165 and the v5 branches in powa-archivist and powa-web), so while it might take some time to finish it's probably a good time to think about how to cleanly add such feature. This is especially true if there's a need for a new table in powa-archivist, as it requires a new major version of the extension and the UI (we only guarantee compatibility between powa-web and powa-archivist for a same major version).

This should therefore also be a good opportunity to try to make a complete and clean feature that is easy to use, even for people without access to the powa repository database, or are just not comfortable doing direct DML there.

@pgiraud do you know if with the new frontend stack it would be easy to add a system of tags that could be sent to the backend when retrieving a datasource to add additional filtering? Saving the non default selection in the session cookie should probably be enough.