#2237 closed task (fixed)

Implement extension mechanism for query filtering

Reported by: Nicklas Nordborg Owned by: Nicklas Nordborg
Priority: major Milestone: BASE 3.18
Component: core Version:
Keywords: Cc:

Description

Queries that are used by table listings in the web client rely on the functionality in the ItemContext and PropertyFilter classes. They are also used by item list synchronization filters.

The current implementation is depending heavily on prefixes for determining how the filter should be interpreted and converted to a HQL restriction. For example,

  • # is the prefix for filtering on annotations. ## enabled searching on inherited annotations
  • §: prefix for filtering on item lists
  • |: any-to-any links
  • /: parent/child items
  • etc...

Every time a new type of filtering is needed a new prefix is required and the the code in PropertyFilter (and maybe ItemContext) need to be modified.

It would be nice if the current implementation could be re-designed to allow extensions to implement their own filtering functions. The new implementation must be backwards compatible or it should at least be easy to convert existing filters (they are stored in the database).

Change History (8)

comment:1 Changed 21 months ago by Nicklas Nordborg

Owner: changed from everyone to Nicklas Nordborg
Status: newaccepted

comment:2 Changed 21 months ago by Nicklas Nordborg

In 7895:

References #2237: Implement extension mechanism for query filtering

Started to work on this. A new action interface QueryFilterAction should be implemented by extensions.

This will probably take effect now for all list pages and item list filters, etc. However, To be really useful for list pages, an extension probably want to pass information also to a related ListColumnAction. For example, the filter implementation will find a list of item ID:s that are used in the query and the column implementation will use cached information to display matched values in the correspoding column.

For this to work, the list pages need to call the new getConfiguredQuery() that also takes a ClientContext parameter. We can probably use the JspContext that is already created in all list pages if we re-order some things in the code.

comment:3 Changed 21 months ago by Nicklas Nordborg

In [7903]

Refereces #2237: Implement extension mechanism for query filtering

The RawBioassays table is now using a single JspContext instance for all extensions which makes it possible for a query filter extension to pass information to a column extension via context variables.

comment:4 Changed 20 months ago by Nicklas Nordborg

In 7911:

References #2237: Implement extension mechanism for query filtering

The IdListRestriction now got support for NOT IN (...).

comment:5 Changed 20 months ago by Nicklas Nordborg

In 7912:

References #2237: Implement extension mechanism for query filtering

Implemented functionality for creating a temporary table with ID values that should improve speed when executing queries with IN or NOT IN having a large list of values. The IdListRestriction has been updated to use this functionality when the list if bigger than 1000 items.

comment:6 Changed 20 months ago by Nicklas Nordborg

In 7914:

References #2237: Implement extension mechanism for query filtering

This should now work on all list pages.

comment:7 Changed 20 months ago by Nicklas Nordborg

In 7915:

References #2237: Implement extension mechanism for query filtering

Added information to the documentation.

comment:8 Changed 20 months ago by Nicklas Nordborg

Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.