We use the toString call on the query in our logs. For some numeric types, the encoded form of the number is being printed instead of the readable form.
This makes tail and some other tools very unhappy... Here is a partial example of a query.toString() that would have had binary in it. As a short term work around I replaced all non-printable characters in the string with an '_'. (collection_id:`__z_[^0.027 collection_id:`__nB+^0.026 collection_id:`__Zl_^0.025 collection_id:`__i49^0.024 collection_id:`__Pq%^0.023 collection_id:`__VCS^0.022 collection_id:`__WbH^0.021 collection_id:`__Yu_^0.02 collection_id:`__UF&^0.019 collection_id:`__I2g^0.018 collection_id:`__PP_^0.016999999 collection_id:`__Ysv^0.015999999 collection_id:`__Oe_^0.014999999 collection_id:`__Ysw^0.013999999 collection_id:`__Wi_^0.012999998 collection_id:`__fLi^0.011999998 collection_id:`__XRk^0.010999998 collection_id:`__Uz[^0.009999998 collection_id:`__SE_^0.008999998 collection_id:`__Ysx^0.007999998 collection_id:`__Ysh^0.0069999974 collection_id:`__fLh^0.0059999973 collection_id:`__f _^0.004999997 collection_id:`__`^C^0.003999997 collection_id:`__fKM^0.002999997 collection_id:`__Szo^0.001999997 collection_id:`__f ]^9.99997E-4) But, as you can see, that is less than useful... I spent some time looking at the source and found that Term does not contain the type of the embedded data. Any possible solutions to this short of walking the query and getting the type of each field from the schema and creating my own print function? Thanks! -- Andrew NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message.
