Skip to content
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

Not handling "type: integer" without a corresponding "format:" #128

Closed
MartinDelVecchio opened this issue Jul 10, 2017 · 6 comments
Closed
Labels
Milestone

Comments

@MartinDelVecchio
Copy link

I am using pyswagger to execute an API call that returns an object with several integer properties. The Swagger for each property specifies only "type: integer"; it does not specify a format (int32 or int64).

When I execute the API, pyswagger raises an exception:

  File "/usr/lib/python2.7/site-packages/pyswagger/primitives/__init__.py", line 182, in produce
    val = _2nd(obj, ret, val, ctx)
  File "/usr/lib/python2.7/site-packages/pyswagger/primitives/comm.py", line 40, in _2nd_pass_obj
    return ret.apply_with(obj, val, ctx)
  File "/usr/lib/python2.7/site-packages/pyswagger/primitives/_model.py", line 29, in apply_with
    self[k] = ctx['factory'].produce(pobj, v)
  File "/usr/lib/python2.7/site-packages/pyswagger/primitives/__init__.py", line 178, in produce
    raise ValueError('Can\'t resolve type from:(' + str(obj.type) + ', ' + str(obj.format) + ')')
ValueError: Can't resolve type from:(integer, None)

I tracked this down to this code in the Primitives constructor (primitives/init.py):

    self._map = {
        # int
        'integer': {
            'int32': (create_int, validate_int),
            'int64': (create_int, validate_int),
        },

It seems that pyswagger requires a format, either 'int32' or 'int64', and fails when no format is specified.

I solved my problem by adding a new entry to the map:

    self._map = {
        # int
        'integer': {
            'int32': (create_int, validate_int),
            'int64': (create_int, validate_int),
            None: (create_int, validate_int),
        },

It does not appear to me that the Swagger specification requires a "format" for an integer type. In addition, the above code shows that pyswagger doesn't treat int32 and int64 differently.

Is there a reason why pyswagger is insisting on a format for an integer type?

Thanks.

@mission-liao
Copy link
Member

@MartinDelVecchio this tool tends be to "spec-compiant", so right now what pyswagger supports is based on this table

I've followed discussions about Swagger Spec on github and didn't notice the case you described is supported (if you find some thread suggested to support it, please feel free to let me know)

And you can extend supported primitives by following this guide

@MartinDelVecchio
Copy link
Author

That section that you linked says, in its third paragraph:

 "Primitives have an optional modifier property format"

It goes on to say:

 "Types that are not accompanied by a format property follow their definition from the JSON Schema."

So the "format" modifier is optional, not required. That page has numerous examples of "type: integer" without any "format" specified.

So I think if you add this entry to your 'integer' key:

 None: (create_int, validate_int),

You will be fully compliant.

In the mean time, I will try achieve this through the primitive creator that you linked to.

Thank you for your quick response.

@MartinDelVecchio
Copy link
Author

Creating my own primitive factory with this:

    my_primitive.register ('integer', None, my_encode_int)

Where my_encode_init() is simply:

def my_encode_int (obj, val, ctx):
    return int (val)

Has solved my problem. Thank you.

@mission-liao
Copy link
Member

@MartinDelVecchio You are right, I missed that part. I'll add primitives without format defined as supported primitives in pyswagger.

@mission-liao mission-liao added this to the v0.8.32 milestone Jul 11, 2017
@mission-liao
Copy link
Member

The fix is released as v0.8.32, please feel free to let me know is any issue occurred.

@MartinDelVecchio
Copy link
Author

I upgraded to v0.8.32, removed my primitive hack, and re-tested. It works.

Thank you for your quick attention to this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants