-
Notifications
You must be signed in to change notification settings - Fork 3
Split-up modules and refactor arguments converting #168
Conversation
Fixed ldoc comment.
It is to make module name consistent with the variable name by which it is used.
Moves are mostly done w/o changes. There are APIs (parameters and return values) that are subject to further refactoring. Removed duplicate code in resolve the function for multihead connections. Part of #166.
0dc051c
to
79d227a
Compare
79d227a
to
cc7a97f
Compare
cc7a97f
to
6d3b455
Compare
local context = opts.context | ||
|
||
check(type_name, 'type_name', 'string', 'nil') | ||
check(context, 'context', 'table') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems a little bit strange. Context is in opts, but it is mandatory argument. Why not make a separate argument? (Maybe I missed something about our concept of opts)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I’ll make it optional sooner or later, expose convert_schema.arguments.convert
as public function and remove arguments.convert_record_fields
.
if type(avro_schema.name) ~= 'string' then -- avoid extra json.encode() | ||
assert(type(avro_schema.name) == 'string', | ||
('avro_schema.name must be a string, got %s (avro_schema %s)') | ||
:format(type(avro_schema.name), json.encode(avro_schema))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe remove assert(sure_to_be_false_condition, message)
with error(message)
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be good to use error / assert according to some specific rules (@Khatskevich had a proposal on the topic, AFAIR?). Now it is arbitrary with bias toward assert.
local avro_t = avro_helpers.avro_type(field.type) | ||
local type_name | ||
if (avro_t == 'record' or avro_t == 'record*') and | ||
field.type.name:startswith(root_name) then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why 2 tabs instead of one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To visually distinguish if-condition from if-branch-body. It seems not being most popular indent style, but I have to use it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it's all in if-condition, I mean, both lines
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
<0 indent>if <cond start>
<2 indent><cond middle>
<2 indent><cond end> then
<1 indent><if branch body>
<0 indent>end
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, got it
type_name = type_name, | ||
}) | ||
context.field_name = nil | ||
table.remove(context.path, #context.path) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we really need to use this mutable context
variable? What do you think about passing (full) path
and a field name
strings into convert()
? It seems to work the same way as with this table.remove(context.path,context.path)
If I am not clear, we can discuss it verbaly
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It just seems a little bit overcomplicated to use explicit stack where we can just pass arguments
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My intension was hide details of the context inside a variable and use/change needed things only where it is needed. It allows to avoid formal arguments that just pass-through them to call of an another function.
@@ -0,0 +1,297 @@ | |||
--- Implementation of module-level functions and functions of instances of the | |||
--- graphql library and a compiled query. | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure about naming? "Implementation" sounds quite wide and uncertain, maybe something like "Instance" and think about as a set of interface functions, connecting user and inner mechanisms of tarantool graphql?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instance was the first variant I consider about :) I was confused with the fact that require('graphql.instance') would return something that is not an instance.
Now I think about it as *.c (impl.lua) and *.h (init.lua) files. Maybe I should rename it to init_impl.lua to make analogue more clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, got your point
Fixes #166.