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

'File' type migration #2

Closed
webron opened this issue Apr 28, 2014 · 11 comments
Closed

'File' type migration #2

webron opened this issue Apr 28, 2014 · 11 comments

Comments

@webron
Copy link
Contributor

webron commented Apr 28, 2014

Following #1 - we should write a migrator that does two things if the type is 'File':

  1. Change the consumes field of this operation to "multipart/form-data".
  2. Change the paramType of the parameter to "form".
@fge
Copy link
Contributor

fge commented Apr 28, 2014

Uhm, IIRC, consumes didn't exist at all in 1.1, did it?

@webron
Copy link
Contributor Author

webron commented Apr 28, 2014

It's not a version migration, it's a general malformation. I want to be
able to be robust and deal with as many malformations as possible, as long
as they don't cause funky problems.

On Mon, Apr 28, 2014 at 4:18 PM, Francis Galiegue
notifications@github.comwrote:

Uhm, IIRC, consumes didn't exist at all in 1.1, did it?


Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-41556565
.

@fge
Copy link
Contributor

fge commented Apr 28, 2014

Uhm, OK, does that make the consumes field mandatory in this case? Because this is currently not validated

@webron
Copy link
Contributor Author

webron commented Apr 28, 2014

Depends on how you look at it. If the type is File, it has to exist with
that value, but it's more complicated than that. It can exist for the
resource itself (at the root of the API Declaration) and that's enough too
(it's inherited).

On Mon, Apr 28, 2014 at 4:27 PM, Francis Galiegue
notifications@github.comwrote:

Uhm, OK, does that make the consumes field mandatory in this case?
Because this is currently not validated


Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-41557540
.

@fge
Copy link
Contributor

fge commented Apr 28, 2014

OK, so, if in a 1.1 declaration I see:

{
    "dataType": "File",
    "paramType": "whatever"
}

then I have to migrate it to:

{
    "type": "File",
    "paramType": "form",
    "consumes": "multipart/form-data"
}

Is that correct?

@webron
Copy link
Contributor Author

webron commented Apr 28, 2014

Yes.
And if in 1.2 you see something similar, you need to 'fix' it to the
correct structure.

On Mon, Apr 28, 2014 at 4:40 PM, Francis Galiegue
notifications@github.comwrote:

OK, so, if in a 1.1 declaration I see:

{
"dataType": "File",
"paramType": "whatever"}

then I have to migrate it to:

{
"type": "File",
"paramType": "form",
"consumes": "multipart/form-data"}

Is that correct?


Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-41558931
.

fge added a commit that referenced this issue Apr 28, 2014
Modify two things:

* when dataType is File, move it to type;
* add a supplementary migration step to modify the contents if type is set to
* File; run this step even if the input JSON didn't have a dataType field to
  start with.
@fge
Copy link
Contributor

fge commented Apr 28, 2014

OK, I have a (tested) fix. Waiting to confirm whether that is fixed for you as well.

@fge
Copy link
Contributor

fge commented Apr 28, 2014

Still waiting for sample JSON for continuing work on the problem ;)

@webron
Copy link
Contributor Author

webron commented Apr 28, 2014

Yup, will get around to it tomorrow.
On Apr 28, 2014 8:43 PM, "Francis Galiegue" notifications@github.com
wrote:

Still waiting for sample JSON for continuing work on the problem ;)


Reply to this email directly or view it on GitHubhttps://github.com//issues/2#issuecomment-41589491
.

@fehguy
Copy link
Contributor

fehguy commented Jan 20, 2015

@webron can i close this?

@webron
Copy link
Contributor Author

webron commented Jan 20, 2015

Sure.

@webron webron closed this as completed Jan 20, 2015
gracekarina added a commit that referenced this issue Nov 24, 2018
cvgaviao pushed a commit to cvgaviao/swagger-parser that referenced this issue Apr 9, 2019
gracekarina pushed a commit that referenced this issue Aug 20, 2019
gracekarina pushed a commit that referenced this issue Oct 9, 2019
gracekarina pushed a commit that referenced this issue Apr 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants