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.
We want to make use of new IDO features without breaking compatibility.
This is a quickfix as otherwise we would currently break everything
below 1.10. Code contains a few TODOs as this needs improvement.
BaseQuery should no longer be abstract but be usable as is as soon as
we stripped ResultSet-specific tasks. As "Base" suggests something that
must be extended, the name no longer fits. So this is SimpleQuery right
now.
Because the `ListController' should only operate on data views,
data views should be a proxy to their underlying queries.
The methods `DataView::fromRequest()' and `DataView::sort()' are from now on deprecated
because they are relaced by `$backend->select()->from($viewName)' and `DataView::order()' respectively.
This partially reverts fcf7f7d6. The original intention was to have
no library code reading config. Moving code snippets to another lib
doesn't solve this. We need quick & easy access to a monitoring
backend, on CLI, in other modules and so forth. Duplicating so much
code again and again is not an option.
I prefer the former way of doing things unless we find a better
solution.
Library code should not read configuration files. The new createBackend() method
from Monitoring/Controller takes care of reading backend configuration and error
handling. The Backend constructor now requires a resource instance.
Since the BaseQuery no longer allows passing the columns to select via
its the constructor, the columns are resolved when set by the
columns() function.
Thomas Gelf
Michael Friedrich
Eric Lippmann
Johannes Meyer