Add Tags programmatically

[beetleskin]

Is there a way to store Tags in the database programmatically? I want to add some Tags while processing a new bag by inspecting some topics and general properties.

In the old version, I created a "auto_tags"-node and added those tags to the user-defined tags in the config. Do I have to do it in the same cumbersome way, or is there a more graceful solution to this?

[chaoflow]

@beetleskin There is no mechanism (yet) to add user supplied tags from within code. What would you expect to happen if:

1. a user removes a tag that was added by a node and the node is rerun?
2. a user added a tag and a node determines later the tag should not be there?

[beetleskin]

In our case, the auto-generated tags are technical, like "bag is complete" (no expected topics missing) and stuff like that. So I suppose user and auto-generated tags would not interfere in general. But yes, I see your point, this could introduces some edge-cases.

However, I did not figure out how to reproduce my old solution due to the S-Expression syntax:

listing_columns =
tags       | Tags          | pill[]    | (list (get "auto_tags[:].text") (tags ))

retults in only one pill for all auto tags and one for all user tags: [auto_tag_1,auto_tag_2] [user_tag_1,user_tag_2]

Any ideas?

Btw., what is the advantage of those S-Expressions? With the python-extractors one had much more control from within the config. Did you write the parser/processor for them on your own, i.e. are they proprietary, or do you extend any common syntax?

[chaoflow]

@beetleskin The list function accumulates all arguments and returns a list of these. It does not unpack the lists. Upcoming release will contain a cat function that concatenates lists.

The advantage of s-expressions is that their syntax is well-defined and trivial to parse, which enables us to execute them not only in python. The listing summary for example is calculated in the frontend.

[chaoflow]

@beetleskin Another aspect is, that for performance of tagging/untagging tags are stored differently than node output and therefore also filtering for them works differently. Given a column that displays the auto tags and actual tags, I'd expect one filter to search for both. This however would mean we'd have to check whether tags are used in the sexpr of any filter and rerun these in case a tag changed in contrast to just adding an sql row.

Given that, so far we always implemented automatic tags as a separate listing column with separate filter field.

What advantages do you see in having them merged?