These are chat archives for ManageIQ/manageiq/performance

19th
Mar 2018
Beni Cherniavsky-Paskin
@cben
Mar 19 2018 09:28
+1 to merging Tag / Classification. I've wanted that ever since I got to know them.
Beni Cherniavsky-Paskin
@cben
Mar 19 2018 09:35
If the redundancy helps performance in any way, we could keep both /path/to/tag and parent_id, but in same table. I suspect the current situation hurts performance, because most code paths ends up being spaghetti between the 2 models, having to load both records, and what's worse losing the big picture behind the mess. For example anything involving Classification name gets silly because it doesn't store its name it has to access Tag's path and chop it up in ruby...
The split also contributed to the APIs being a mess. I suppose there are/were some logical layers but now it feels just spread randomly between ~5 places, I always guess where I should come in...
Beni Cherniavsky-Paskin
@cben
Mar 19 2018 09:40
Another issue related to the spread functionality is having too many ways to refer to tag(s):
  1. a Tag
  2. a Classification
  3. string — a full Tag path (confusingly called name)
  4. string — the "category/name" part, with namespace being assumed or passed in another arg
  5. a category (represented as any of the above) + separate tag name [this combo is thankfully rare]
  6. string representing many tags(!), space delimited with some quoting rules
    [functions that take this thankfully also take an array]
This message was deleted
Beni Cherniavsky-Paskin
@cben
Mar 19 2018 09:56
See Tag.parse for gory details of (6). What I can't excuse is some place that have arrays and do .join(" "), apparently to generate (6)?
End of rant, for now :).
Keenan Brock
@kbrock
Mar 19 2018 12:28
@cben we may consider using ancestry to store hierarchical tags. The string munging frustrates me the most