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
Well... I didn't want to commit this before creating single-button
forms for enabling/disabling modules. However part of this accidentally
made it through, so let's finish it.
Still some work to do, but it already looks far better like this.
refs #4095
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.
Those signs are URL-encoded and therefore not "seen" before decoding
the "key" part when the sit in front of the = sign. Same goes for
standalone ones. Fixed.
This adds quite a bunch of changes. Part of the filter-modifying
complexity has been moved to the filter, the editor widget itself
now makes use of new filter capabilities such as changing operator
or expression type.
A bunch of things happened here. We distinct FilterChains (or, and,
not) from FilterExpressions (less, greater, equal...). We make use of
our new URL-Parser. We can directly address anonymous filter components
for editing filters. Too much things to explain them in detail, a filter
documentation will follow.
Raised connection timeout, helps when talking to DB servers behind
weak links. Please note that I'm not sure whether this really is a
better default.
While it doesn't matter with local sockets, connection overhead will
have an impact with remote database servers. We have to reconnect with
every single request. Persistent connections seem to be no longer as
errorprone as they used to be, but I'd still refuse to switch them on
by default.
What we need is a config setting for connection persistancy and wizards
strongly suggesting to use this when working with remote db servers.
Class names in namespaces should not be chosen as once we didn't have
such. The fact that we already did "use Db\Connection as DbConnection"
is the best hint that naming was wrong.
So this patch renames Db\Connection to Db\DbConnection and does the
same with DbQuery. DbQuery has been adjusted to fit our new SimpleQuery
and to handle the new Filter implementation.
New interface ConnectionInterface attempts to aggregate things.
Extended Filterable interface, added Filter-related functions. Please
note that apply will probably get dropped later on, I'll keep it for
compatibility reasons right now.
refs #6418
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.
When optional classes and php extensions like pgsql and additonal Zend-Pdos are
actually required by creating a new resource or authentication backend,
perform a check and display a warning instead of just throwing an exception.
refs #4788
This interface is intended to be used within the data views and monitoring controllers. The monitoring list
and show controllers should only query data views instead of the actual query. Thus a data view is required to
implement the QueryInterface, which will be changed later.
The name is not final because it somehow conflicts with the Queryable interface which is also marked as work in progress.
The BaseQuery forwards fetch*() function calls to its datasource with the
query as first parameter since the datasource implements the actual fetching functionality.
There's no interface for fetch*() functions on the datasource level yet.
The previous implementation always created both the count
and the select query.
For readability the property baseQuery has been renamed to select which the
IDO queries must take into account.
This commit breaks the application as it introduces incompatible changes which
will be adopted bit by bit.
Since the filter functionality is subject to change it's removed from the BaseQuery.
The functions setOrderColumns() and getOrderColumns() are deprecated because they're
replaced by functions in the Sortable interface.
Further the Sortable interface now defines the sort constants ASC and DESC and are
thus removed from the BaseQuery. In addition the sort constants are no longer integers
but strings.
The distinct() and isDistinct() functions are removed because they're database specific.
They have been introduced with changes in the PivotTable implementation which should
actually not call distinct blindly anyway.
Thomas Gelf
Eric Lippmann
Matthias Jentsch
Johannes Meyer
Alexander Klimov