Skip to content
This repository was archived by the owner on Apr 14, 2022. It is now read-only.

Split-up modules and refactor arguments converting #168

Merged
merged 9 commits into from
Jun 14, 2018

Conversation

Totktonada
Copy link
Member

Fixes #166.

@Totktonada Totktonada added the code health Improve code readability, simplify maintenance and so on label Jun 6, 2018
@Totktonada Totktonada self-assigned this Jun 6, 2018
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.
@Totktonada Totktonada force-pushed the gh-166-refactor-arguments branch from 0dc051c to 79d227a Compare June 13, 2018 02:10
@Totktonada Totktonada force-pushed the gh-166-refactor-arguments branch from 79d227a to cc7a97f Compare June 13, 2018 02:15
* Generate object arguments in avro-schema format first.
* Generate object arguments for subrecords.
* Use full path for a GraphQL type name where possible.

Also:

* Added apidoc-lint target and added to CI.

* Part of #166.
* Fixes #73 (2nd bullet).
* Fixes #163.
* Fixes #46.
@Totktonada Totktonada force-pushed the gh-166-refactor-arguments branch from cc7a97f to 6d3b455 Compare June 13, 2018 02:18
@Totktonada Totktonada changed the title WIP: Split-up modules and refactor arguments converting Split-up modules and refactor arguments converting Jun 13, 2018
@Totktonada Totktonada requested a review from SudoBobo June 13, 2018 16:33
local context = opts.context

check(type_name, 'type_name', 'string', 'nil')
check(context, 'context', 'table')
Copy link
Contributor

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)

Copy link
Member Author

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)))
Copy link
Contributor

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) ?

Copy link
Member Author

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
Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

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

Copy link
Member Author

@Totktonada Totktonada Jun 14, 2018

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

Copy link
Contributor

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)
Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Member Author

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.

Copy link
Contributor

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?

Copy link
Member Author

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, got your point

@Totktonada Totktonada merged commit 7569a7d into master Jun 14, 2018
@Totktonada Totktonada deleted the gh-166-refactor-arguments branch June 14, 2018 11:39
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
code health Improve code readability, simplify maintenance and so on
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants