Poblems with Kepler when query returns too many rows

[Begoña Bonet]

I need to define a Database field based on a query over an external database. The query finds all the configuration items that can be related with the issue thas is being created by users. Users create these kind of issues to inform about bugs of these configuration items.

The number of possible configuration items to relate with the issue is about 8000 and the performance of JIRA is so bad that even the Jira instance goes down.

Do you know any other plugin able to manage with so many results of a query?

Our requirements are:

1) Validate that the configuration item enter by user is correct

2) if it's possible to help user to select the rigth value showing him the list of possible configuration items. It can be through other kind of interface control.... for example opening a window with a filter included will be a good solution por us

3) All the possible configuration items are registered in an external CMDB and we make the query over it to validate the entered value.

Any sugesstions?

[Begoña Bonet]

We have tried to solve this using 2 related fields. The value of the first one can filter the number of results obtained by the query of the second field.

The problem with this solution using Dynamic Queries is that the value of the first field is entered at the same action than the second one (both in the creation of the issue).

[Begoña Bonet]

Somebody knows how we can use something similar to the solution for including "users" into "groups"? In this case, to include a user into a group a window is opended with all users and a filter in this window can be used to filter users. Also navigation is allowed in this kind of user interface control.

[Radu Dumitriu]

Our DBCF plugin was not intended for such heavy recordset. The SQL config allows you to narrow your results to a human bearable size (using other custom fields values, etc, check http://confluence.kepler-rominfo.com/display/DBCF/Dynamic+Query). We plan for a paid version of it able to handle huge recordsets, but this will need a complete re-write.