Hi Dojo,
I'm wondering what's the benefit of using type="custom" over type="retrieved" in table ArrayOptions. From what I understand from the docs, custom columns cannot be accessed via QActions etc and its main purpose seems to be in its restrictive properties. I can't clearly see why I should not use retrieved columns over custom columns however.
1) Are there specific use cases / benefits of custom columns over retrieved columns?
2) Will changing a custom column to a retrieved column cause any major change or impact I should be aware of?
Thank you!
Hi,
Both type Custom and Retrieved are used when we want to fill in the table via code (could be your qaction, could even be another element / script).
The main difference is that custom does not support multiple cell sets for that column, where retrieved does.
This is a historical thing: we first had type Custom to fill in data with methods that would set 1 cell at the time. (e.g. set parameter by key)
Later we improved and supported methods to set multiple cells for that column (e.g. fill array)
Today, best practice is to simply use retrieved every time the table is filled by code. This way we allow multiple cells (different rows) for that column to be filled in via 1 method.
Personally I only use type Custom when the column is a button. This way it is visually clear for me (when looking at the table xml definition) what is supposed to be filled in (column params of type Read) and what is a button (column param of type write). This is just a personal preference. using retrieved for write params will also work, it just does not make any sense to have logic to fill it with data (since it cannot hold any)
Hope this clears things up.
1) Are there specific use cases / benefits of custom columns over retrieved columns?
See above. I would always go for retrieved to allow multiple sets (different rows) for this column.
2) Will changing a custom column to a retrieved column cause any major change or impact I should be aware of?
No, using a method that sets 1 cell in a column that supports multiple sets will still work.
Floris,
You should not mix snmp and retrieved columns (e.g. column 1 snmp, 2 retreived, and 3 snmp again) because snmp also allows multiple sets in that column.
This would basically break your visualization of the polled snmp data since (based on the polling method) snmp data could get ingested into the retrieved column but will not be displayed.
Since custom does not allow multiple, the snmp data can’t enter there = you don’t have the problem of mismatching data. You do create a load-increase limiting the sets of the column filled by logic to 1 by 1.
So always add columns that are filled by logic at the end of your snmp table.
and aim to use retrieved in order to use the most efficient method to fill in data.
Thanks Floris and Mieke!
If I remember correctly, the main area where custom columns could still be important is when mixing with SNMP columns, also for historical reasons.