Allow empty model objects in response example definitions

[ncreep]

Hi,

I'm trying to render an example value with the Swagger renderer. My example value contains an empty list and thus JsonToJsonSchema throws:

new IllegalSchemaException("Cannot use an empty list to generate a schema!")

In my case, it would still be useful to actually render the example value, despite not knowing the exact type of the array (I don't care if it's considered to be Object or something).

Could it be possible to not throw the exception and have some fallback rendering of the example value without a schema?

Thanks

[daviddenton]

Is there any reason that the example list has to be empty - for instance is it the case that the type of object that goes into the list is dynamic?

[ncreep]

In the specific use-case I have it's complicated to initialize a valid value (there are a number of nested collection values there, and it just adds noise in the code). And generally I would like to lower the barrier for creating the example values, so that people not lose their motivation to provide them.

[daviddenton]

I took a quick look at defaulting the value instead of throwing the exception but that broke the model definition rendering (it lost the subsequent definitions), so I think this will require a larger change - possibly reworking the renderer algorithm.if you can spot an easy fix then please suggest :)

[ncreep]

I'll try looking into it when tackling #41, though since I'm new to the library, I'm not sure what I'll come up with...

[daviddenton]

@ncreep One more thing that might help with regards to the "generating valid examples" problem - for our internal apps using fintrospect, we use Databob to generate valid random values for objects with no boilerplate. It works out of the box on everything we've tried, and you can provide generators for any other type that you might need: https://github.com/daviddenton/databob

[ncreep]

Thanks for the suggestion. Although I'm definitely in favor of generating randomized data (be it for tests or for the schema examples), sadly, our codebase is not there yet, it'll take non-trivial effort to get there. And some of the types that we are using are quite messy (as in, deeply nested multiple implementations of a unsealed trait), the problematic one that triggered this issue being one of them. Also, taking a closer look at Databob, I see that it uses reflection behind the scenes. I'm slightly hesitant to introduce libraries that use reflection, and instinctively lean towards macro/Shapeless-based libraries. Though this point will have to be reevaluated once I actually go forward with the data-generation approach.