Switch to list of lists of tags for transaction results, begin block, and end block

[cwgoes]

Users will want to query "events" - parameterized logs of particular state transitions, such as account debits/credits, delegations, slashes, etc. - and any number of events may occur per transaction or per begin block / end block function.

[mappum]

I liked the simplicity of a single list of tags, but I can see how groups of tags would be more powerful for advanced queries. Would the indexing code be overhauled for this new system, e.g. querying based on the parameters of an event?

[cwgoes]

I liked the simplicity of a single list of tags, but I can see how groups of tags would be more powerful for advanced queries. Would the indexing code be overhauled for this new system, e.g. querying based on the parameters of an event?

Besides this test file, I can't find any documentation on the indexing system / query syntax. The syntax in that file seems pretty flexible, but just reading it I have a hard time understanding whether or not particular queries would be efficient (we'll want the ability to find transactions by event parameters quite quickly).

cc @melekes thoughts?

[melekes]

I liked the simplicity of a single list of tags, but I can see how groups of tags would be more powerful for advanced queries. Would the indexing code be overhauled for this new system, e.g. querying based on the parameters of an event?

do we need these advanced queries before launch?

what do we need exactly? couldn't it be done with small modifications?

Besides this test file, I can't find any documentation on the indexing system / query syntax.

https://godoc.org/github.com/tendermint/tendermint/rpc/core#Subscribe
https://github.com/tendermint/tendermint/blob/master/libs/pubsub/query/query.peg

whether or not particular queries would be efficient

the indexer we're using right now is pretty dumb. if we're talking about fully fledged event system, we will need indexes (BTrees) for tags. In that case, it might make sense to implement tendermint/tendermint#1161, so we don't reinvent the wheel.

[zramsay]

tendermint/tendermint#1859