Implement support for QFF_SPLIT_TIMESTAMP
I am very very unhappy with this patch. We have to do this, in orderto be compatible with the Python code and behaviour, but there's lotsof duplication; both the Python and the Haskell code will need to becleaned up and simplified (we don't need QFF_* at all)....
Add NFData instances for query results
This allows us to ensure that query results are strict as we buildthem, instead of being lazy and only evaluated when the reply is sentover the Luxi interface.
Signed-off-by: Iustin Pop <iustin@google.com>Reviewed-by: Helga Velroyen <helgav@google.com>
Simplify a bit the FilterRegex JSON instance
Implement opcode summary support
This implements in the Haskell codebase the opcode summary. As opposedto Python, we always use custom code for formatting, since we don'twant to use dynamic attribute lookup.
To test this properly, we need to change MetaOpCode to record-syntax,...
Log only partial response in Luxi when in debug mode
Currently, we log the entire response (at debug level) in the Luxireplies. This is not a good idea; the logging library operates onstrings, and as such it will use huge amounts of memory: without debug...
Make Query operators enforce strictness
Currently, the query operators (binop, etc.) create thunks, instead offorcing the evaluation of the simple boolean results. This results inhigher than needed memory use.
Signed-off-by: Iustin Pop <iustin@google.com>...
Optimise recursive Query filters
Currently, the And and Or filters use very nice code, e.g. in case ofOrFilter:
any id <$> mapM evaluateFilter flts
However, looking at the memory profiles shows that application ofany/id to monadic values via '<$>' does not work nicely, losing the...
Remove read instances from our Haskell code
It turns out that optimising 'read' derived instances (via -O) forcomplex data types (like OpCode, or the various objects) can be slowto very slow. Disabling such instances results in (time make$all_our_haskell_binaries) large compile-time savings and also smaller...
Split 'Query.Language.ItemType' in two sub-types
The QR_VIA_OP/QR_VIA_LUXI types in Python are using yet anothervalidation mode: QR_VIA_OP is the base type, and QR_VIA_LUXI extendsit (when doing luxi queries). But on the wire they have the samerepresentation....
Fix docstrings for the Filter type
While looking at the opcode docs and clicking accidentally on thefilter type, I saw that the haddock formatting is broken due tonon-escaped use of special chars. Let's convert the ascii-likeformatting to haddock, and have nicer apidoc....
View revisions
Also available in: Atom