[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Additional "in" operator for fields being lists of strings
From: |
Jose E. Marchesi |
Subject: |
Re: Additional "in" operator for fields being lists of strings |
Date: |
Thu, 30 Jul 2020 20:03:24 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
Hi Marcin!
> I would like to propose an additional "in" operator which would treat
> field's string value as a space-separated list and check if the
> specified token is present.
>
> I know that fully normalized relational databases would look like this:
>
> Device: plumbus
> Tag: dinglebop
> Tag: fleeb
> Tag: plubus
> Tag: grumbo
>
> But it might be quicker to use when constructed in the following manner:
>
> Device: plumbus
> Tags: dinglebop fleeb plubus grumbo
I already considered adding something like this. These are my notes:
* Multi-valued enum fields :PROJECT:
** Purpose
It is common to have several "enumerated" fields in a single record. For
example, the entities impacted by a bug report in a bug tracking system:
Id: 102
Title: The timing of load instructions is missing cycles.
Entity: ERC32
Entity: LEON2
Entity: LEON3
The verbosity is a bit too much, which leads to big records and can impact
readability.
** Outcome
The usage of lists of enumerated values is allowed. The values are
separated by one or more blank characters. For example:
Id: 102
Title: The timing of load instructions is missing cycles.
Entity: ERC32 LEON2 LEON3
Commas, which are ignored, can be optionally used as well:
Entity: ERC32, LEON2, LEON3
** Impact
The support of multi-valued enumerated fields would have the following impact
in recutils:
- Currently the sex evaluator is not aware of the existence of enumerated
values, treating enumerated fields as strings. In order to support
multi-valued enumerated fields the interpreter must be equipped with
enum-specific operators. These operators would scan the list of values
and implement the proper semantics.
Your 'in' operator seems to be a step in this direction, but if I
remember well I originally intended this to be transparent given the
field is declared as an Enum, i.e., to this record type:
%rec: Device
%type: Tag enum dinglebop fleeb plubus grumbo
You could write records with multiple Tags in two ways, as you suggest:
Device: plumbus
Tag: dinglebop
Tag: fleeb
Tag: plubus
Tag: grumbo
or:
Device: plumbus
Tag: dinglebop fleeb plubus grumbo
(Note Tag no Tags)
And then you could use the normal == or ~ operators like:
Tag == "fleeb" || Tag == "grumbo"
As I observe in my notes above, this would require to make ==, !=, <, >,
~ and the like aware of enumerated fields.
Supporting commas was mainly in order to ease supporting the Debian
package format...