[Tarantool-discussions] RFC - distributed SQL, step #1 - AST
Nikita Pettik
korablev at tarantool.org
Wed Nov 25 12:44:56 MSK 2020
On 25 Nov 01:06, Timur Safin wrote:
>
> Exporting AST as cdata is easy to do, but in this case it will be
> inconvenient to manipulate AST nodes, before sending to cluster nodes.
> So there is 2nd, more idiomatic approach suggested - to convert AST
> to nested Lua object/tables.
Hm, why do you need those tables? Serialization into msgpack can
be done inside SQL internals.
> Which should simplify some massaging
> and provide natural way to serialization to msgpack.
>
>
> SYNOPSIS
> ~~~~~~~~
>
> .. code-block:: lua
>
> local sql = require `sqlparser`
>
> -- parse, return ast, pass it back unmodified for execution
>
> local ast = sql.parse [[ select * from "table" where id > 10 limit 10 ]]
Should this be public API? Alternatively, we can hide it in sql.internals.
> assert(type(ast) == 'cdata')
> local ok = sql.execute(ast)
>
> -- free allocated memory, like box.unprepare but for ast
> sql.unparse(ast)
I don't like unparse name. In fact even unprepare is a bad name,
it should be called sort of deallocate. I suggest sql.release_ast()/
sql.free_ast() naming.
> -- raw access to cdata structures
> local cdata = ast.as_cdata()
> if cdata.ast_type == ffi.C.AST_TYPE_SELECT
> handle_select_stmt(cdata.select)
> end
>
> -- Lua access to structurs as Lua tables
> local tree = ast.as_table()
> if tree.type == AST_TYPE_SELECT
> handle_columns_list(tree.select.columns)
> handle_where_clause(tree.select.where)
> limit = tree.select.limit
What's the purpose of these handles?
> end
> -- massaging with tree data
>
> -- serialization
> local msgpack = require 'msgpack'
> local to_wire = msgpack.encode(tree)
>
> -- networking magics ...
> -- ... deserialization
> local table = msgpack.decode(from_wire)
> ast.set_tree(tree)
> sql.execute(ast)
>
>
> Regards,
> Timur
>
> P.S.
>
More information about the Tarantool-discussions
mailing list