Hi,
I would do it that way:
* Create a new table wingo_df_values (field_id, field_key,
field_value) with unique (field_id, field_key)
* change the backend module for Dropdown fields where the possible
values are stored to the new table (every time the dynamic field
is changed)
* use that new table in the SQL query
- Renée
Am 10.06.2016 um 14:13 schrieb Olivier Macchioni:
Hello dear list,
I’m trying to export a list of tickets directly from the OTRS DB - I’m computing 20 columns, there are 7 joins… the request is not that small…
And it takes approx. 50 seconds to generate 5’000 rows I need. Knowing that I will eventually need to export much more than 5’000 rows, this is not acceptable.
If I remove *only* the 4 columns where I compute the value of some “Dropdown” dynamic fields linked to tickets, the times drops down to 3 seconds…
So I must be doing something wrong in the way I compute the value of dynamic fields…. or maybe the design of the DB itself is suboptimal?
The best solution I’ve found so far is a poor man’s parser on the YAML content of dynamic_field.content:
SELECT id,
(SELECT regexp_replace(config, '.*' || dynamic_field_value.value_text || ': ([^\n]+)\n.*', '\1')
FROM dynamic_field_value
JOIN dynamic_field ON dynamic_field.id = dynamic_field_value.field_id
WHERE dynamic_field_value.object_id = ticket.id
AND object_type = 'Ticket'
AND dynamic_field.name = 'Category') AS "Category"
FROM ticket
WHERE ticket.tn = '10479715'
Does anyone have a better idea?
Thanks,
Olivier
P.S. I’m using PostgreSQL - it would have been nicer to store the data in JSON format, which is natively supported, it could have save some precious CPU cycles but well...
---------------------------------------------------------------------
OTRS mailing list: otrs - Webpage: http://otrs.org/
Archive: http://lists.otrs.org/pipermail/otrs
To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/otrs
--
Perl / OTRS development: http://perl-services.de
OTRS AddOn repository: http://opar.perl-services.de