key=23;0;0;0;0 and key=23;;;; lead to division by zero exceptions
This should fix this by ignoring empty strings for min/max (formerly
it got "converted" to float(0)) and also ignores min == max.
fixes#6828
The perfdata helper did an improper limitation as it might have skipped
valid values due to applying the limit before the filter. When not in compact
view the helper now also shows non-piechart values by using their raw
representation.
refs #6515
Prior to this change the PerfdataSet only knew the labels of a performance
data value which prevented the Perfdata object from being used
individually.
refs #6515
This re-introduces expensive columns been disabled time ago and adds
even more to it. We are now showing last comment, last ack comment and
service problem count on hosts in list views.
It still costs performance, but seems that we can stand it. I'd like
to add more like this to the host view.
This is still experimental. We normalize a lot of columns, this allows
us to sort in a convenient way while having nice "showable" columns.
When used as filters (same goes for ordering) however, functions and
operations on table columns often hinder the db from using indexes.
The new filter implementation allows us to override query creating per
single column, that's what this first sample is trying to show. We still
need to fix alias handling, so unfortunately I have to deal with "real
columns" in the case construct.
Performance gain in large environments is impressive, more to come.
I'd like to reintroduce those columns, showing last object comment
and so one. Those joins are costly, we can fetch host comments way
easier directly from host object once we are here. But I guess we
don't even need it.
Stumbled across two issues here:
* It's currently not possible to fetch all (*) columns from a DataView
* Backends are not able to tell their names
Worked around the first issue by naming all columns and implemented a
quick & dirty solution for the second one.
Different changes have been applied:
* Allow integer unix timestamps as parameters for timestamp columns
* Remove alias-rewriting from Url class
* Remove all traces of raw_timestamp
* Use new filters
This takes care of timestamp columns, modifies queries in a way not
depending on db functions, filters are passed through to subqueries
for better performance.
There are too many view scripts fiddling with namespaces. There is
still the url helper, not sure why it's not going to be used. I may
roll this back one far day...
Every monitoring controller needs $backend, so why declaring it over
and over again. Created "moduleInit" dummy function in our base action
controller to allow such implementations without polluting init().
It doesn't make much sense to sort history by "hostname" hardcoded to
service-only host columns. Default is now timestamp DESC, internally
this is mapped to raw_timestamp.
This was never thought to be used in frontends. Frontend code ALWAYS
needs to work with unix timestamps, raw timestamps are used internally
(e.g. between View and Query) to achieve better search and sort
performance.
I guess this needs some more investigation, desiredColumns are the
ones the user asked for ([alias => ]column), with column being once
again an alias in the "real" query. Alias resolution used to work
better long time ago, we should reflect on this.
IDO version is cached in a session namespace. This fails where you
are using multiple IDO backends with different versions. We still have
no backend-specific base class where we could handle this, so for now
I continue to do so in the IdoQuery.
This patch creates one namespace per Host/dbname combination.