-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
InvalidProtocolBufferException with complex queries #31
Comments
ZetaSQL's Java API uses a GRPC service to call into the actual C++ implementation of ZetaSQL. By default, the serialization logic of that communication allows for a nesting depth in protobuf messages of up to 100. However, long queries can exceed that level of nesting and as a result cannot be analyzed by default. This implements a reflection-based patch that allows users to override that limit to a greater number. This is brittle by design and should be used with caution. Fixes #31
ZetaSQL's Java API uses a GRPC service to call into the actual C++ implementation of ZetaSQL. By default, the serialization logic of that communication allows for a nesting depth in protobuf messages of up to 100. However, long queries can exceed that level of nesting and as a result cannot be analyzed by default. This implements a reflection-based patch that allows users to override that limit to a greater number. This is brittle by design and should be used with caution. Fixes #31
ZetaSQL's Java API uses a GRPC service to call into the actual C++ implementation of ZetaSQL. By default, the serialization logic of that communication allows for a nesting depth in protobuf messages of up to 100. However, long queries can exceed that level of nesting and as a result cannot be analyzed by default. This implements a reflection-based patch that allows users to override that limit to a greater number. This is brittle by design and should be used with caution. Fixes #31
We implemented a workaround for this issue in release ZetaSQLPatcher.patchMaxProtobufNestingDepth(1000); For context, this happens because ZetaSQL's Java API uses a GRPC service to call into the actual C++ implementation. By default, This feature of the toolkit monkey patches the ZetaSQL's GRPC client and modifies that limit to the value provided by the caller. Setting the limit to 1000 seems like a reasonable target and should be able to parse and analyze queries much larger than before. However, do use this with caution and only when needed. This uses reflection to modify the internals of ZetaSQL's GRPC client at runtime. The approach is brittle by design and could potentially break in a later release. Consider the feature as experimental. In the future, once increasing the limit isn't experimental in |
Hi,
We are trying to employ ZetaSQL Toolkit for our SQL-based lineage and decision-making processes. However, with some complex queries (around 20 temp tables and a CTAS script that uses all of the temp tables), we encounter an error that prevents us from properly parsing some of the queries that we use. The code lines below represent a simplified version of our implementation in Java. During execution, the program throws the exception below.
It seems that the
next()
function in theAnalyzedStatement
class analyzes the query while creating a communication channel between the client and BigQuery itself. It also seems that theCodedInputStream
class in theprotobuf-java
library configures the limits of this communication channel. According to the error message that we got, the default value ofdefaultRecursionLimit
which is 100, is not sufficient for our case. Could you help us to deal with this issue?The text was updated successfully, but these errors were encountered: