I'm running down some potential issues with Output Sets, and I think there may be some issues with our v14.1 conversion. The first issue is that my old custom elements don't look quite like the documentation says they should. They work, but we're definitely having performance issues somewhere.
Documentation:
Here's my config, note the lack of the !. placeholder. I don't know if this is something I did or a result of the conversion, and which is correct:
The second issue is that the output set groups seem messy. Here are all the ones for "Constituent":
Interestingly, Constituent 1 has one element, "Constituency List", and Constituent 2 has all the regular info (name, address, etc.). Contribution is worse:
Is this likely a result of an upgrade issue, bad initial setup (I haven't looked at output sets in a long time) or are they supposed to look like this for some reason?
As I dig in a little further, it seems like perhaps we have broken out Output sets to have a "view" definition in TR_QUERY_ELEMENT_GROUP, and then the query elements in TR_QUERY_ELEMENT, instead of having the same table/view/function with a where clause defined over and over instead look to a group defined in TR_QUERY_ELEMENT_GROUP. This is fine, but the selection element in the client is using this Element Group to organize elements instead of using the Category (as defined in TR_QUERY_ELEMENT_GROUP) which is clearly what it should be using instead. Known bug or bad implementation decision?
Hi Gawain
Output Elements in v14.1+ are grouped by the Output Element Group. Category is only required to Save TR_QUERY_ELEMENT_GROUP in the System Tables – it’s not currently used elsewhere in Output Sets/Elements.
During the upgrade, the process assesses the Elements’ data_where and data_from fields. If there are a number of elements that have matching values in both fields they are put into the same Output Element Group. If these fields have even a slight difference, then they are placed under a different Output Element Group.
It is expected that some manual tidying might be required after the migration. This doc should help explain the process https://www.tessituranetwork.com/en/Files/Docs/v14_1/Output-Set-Migration
The !. is required on all elements unless they are an aggregate element i.e. SUM() etc., OR they reference the Tessitura Virtual Tables (Address, Customer, Eaddress, Memberships, Phone, Salutation). You'll be able to determine this by looking at the information in data_where and data_from in TR_QUERY_ELEMENT_GROUP.
If in doubt, open a TASK ticket.
Cheers
Sandra