dds content filtered topic #2303
Draft
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Initial version of sql-like expression syntax implementation for content filtered topics with basic tests. Parsing is based on precedence climbing method with couple of basic expression optimizations (such as `const` folding where it's obvious enought). Result of the parsing is syntax tree with hashtable, the last one refer to `param` set which is used to propagate the user's values over execution tree. As a result user get a optimized tree with hashtable of `variable` in that case or constant if applied `parameters` result to `constant` value during execution. Parser applying SQL-like typecasting for operations of not strictly the same type, which not limit the user in `param`/`variable` type selection. -------------------------------------------------- BTW current implemnetation have some restriptions/limitations such as: - Poor validation and expr. warn/error user notification system. - No 8-byte unsigned values support (which is important to support all idl defined types). - Lack of some very obvious from user perspective optimizations. And probably even more than that, but on that particular stage implementation if already pretty usefull.
Common filtering entry point (currently `function`, `expression` base) for simplify filter propogation on `reader` and `writer` side, which allow hide backend of filter implementation from `collect` and `write` operations under `init`,`fini`,`accept_reader`,`accept_writer` if. -------------------------------------------------- Potentially interface can be limited even to single `accept` method, but since collect and write operations require a bit different set of arguments it's well enough to have both.
Replace old filtering mechanism dependent on topic entity filter filed
with QoS based content filter which propagate to rd/wr entities as a
`common` dds filter.
Described changes also required tiny tweaking of old filtering API, as a
result by applying filter on a topic entity, filter applies on all
topics with the same `name`, `type` and `participant` entities ('cause
of specific of topic QoS mechanism).
API extended with a new methods regarding to new filtering definition.
But all the old API functions keep unchanged.
Splinter1984
force-pushed
the
flt_topic
branch
4 times, most recently
from
6c50bac to
9c93af7
Compare
Splinter1984
force-pushed
the
flt_topic
branch
from
9c93af7 to
53a8258
Compare
During type-build process caused by filter parameters rebind, temporary register constructed type with hash based on `fileds` and parent type.
local registration of filter type with name + fields hash value as a type_name, with avoid of "double" registration of fields with the same type.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Content filtered topic.
This PR is initial implementation of content filtered topic according (mostly) to dds spec.
The implementation introduce new dds_filter entity which is set over QoS and propogates to
reader/writerendpoints (which is acrually own and operates filters). Don't forgent about a previous topic_filter API, whose "backend" replaced with new filter entity, which leads to tiny change in old-API behavior1.Since old-API didn't changed, the really new thing for the user is a
expressionkind filter. Basically isnstead of function user may specify expr. such as"?1 + a >= b.a * c OR (?2 AND d)"where?1and?2areparameterswhich can be applied as one of the supported2 types (int64_t,double,string,blob) during runtime using corresponding API functions.a,b.a,canddare filed names of filtering topic type according toidltypedefinition3.
Footnotes
Topic entities created with the same
participant,topic_nameandtype_nameshare the same QoSes, as a result if one of the entities defining a filter another catch it accordingly. ↩There is still missing implementation of unsigned type, which is required to fully map idl types. ↩
Current implementation don't allows nothing but
structandprimitivetypes to be used within expressions. ↩