This fixes the problem with base-16 encoded values which may start with
digits: 015AB.... In such cases, the parser recognizes them as numbers
but fails to parse because of the follow-up characters (AB).
```
failed to parse tm.events.type=Tx AND hash=136E18F7E4C348B780CF873A0BF43922E5BAFA63:
parse error near digit (line 1 symbol 31 - line 1 symbol 32):
"6"
```
So, from now on we should quote any values. This seems to be the way
Postgresql has chosen.
query parser
use parser compiler to generate query parser
I used https://github.com/pointlander/peg which has a nice API and seems
to be the most popular Golang compiler parser using PEG on Github.
More about PEG:
- https://en.wikipedia.org/wiki/Parsing_expression_grammar
- https://github.com/PhilippeSigaud/Pegged/wiki/PEG-Basics
- https://github.com/PhilippeSigaud/Pegged/wiki/Grammar-Examples
rename
implement query match function
match function
uncomment test lines
add more test cases for query#Matches
fix int case
rename events to pubsub
add comment about cache
assertReceive helper to not block on receive in tests
fix bug with multiple conditions
uncomment benchmark
first results:
```
Benchmark10Clients-2 1000 1305493 ns/op 3957519 B/op 355 allocs/op
Benchmark100Clients-2 100 12278304 ns/op 39571751 B/op 3505 allocs/op
Benchmark1000Clients-2 10 124120909 ns/op 395714004 B/op 35005 allocs/op
```
124ms to publish message to 1000 clients. A lot.
use AST from query.peg.go
separate pubsub and query packages by using Query interface in pubsub
wrote docs and refactor code
updates from Frey's review
refactor type assertion to use type switch
cleanup during shutdown
subscriber should create output channel, not the server
overflow strategies, server buffer capacity
context as the first argument for Publish
log error
introduce Option type
update NewServer comment
move helpers into pubsub_test
increase assertReceive timeout
add query.MustParse
add more false tests for parser
add more false tests for query.Matches
parse numbers as int64 / float64
try our best to convert from other types
add number to panic output
add more comments
save commit
introduce client argument as first argument to Subscribe
> Why we do not specify buffer size on the output channel in Subscribe?
The choice of buffer size of N here depends on knowing the number of
messages server will receive and the number of messages downstream
subscribers will consume. This is fragile: if we publish an additional
message, or if one of the downstream subscribers reads any fewer
messages, we will again have blocked goroutines.
save commit
remove reference counting
fix test
test client resubscribe
test UnsubscribeAll
client options
[pubsub/query] fuzzy testing
do not print msg as it creates data race!
Anton Kaliaev