Open SamuelMarks opened 9 years ago
Nice idea, but will you implement this as an optional feature?
I tried to explain it, and then discuss.
The generated code can be divided into two categories: overwritable and non-overwritable.
The code overwritable is totally defined by swagger docs, and the code non-overwritable is generated on first time, then maintained by the user.
The overwritable codes include:
swagger-py-codegen' s purpose is to make those overwritable codes can be simply updated when the swagger doc is changed.
The other codes, for example, views, views content is not totally decided by swagger-py-codegen, so it's content will not be overwritten by default.
SQLAlchemy's model like views, the user will handle it contents, so it should be non-overwritable by default.
Another purpose of the project is: generates the necessary code for make a running application as the swagger doc defined.
The SQLAlchemy model is not a necessary condition for the working app, but the model code may be very useful for some scene.
So if this is an optional feature, we will be very pleased to accept your PR.
p.s. I intend to implement a custom template feature so that it can adapt to more special scene.
Thanks.
Yeah, I've been thinking about this, essentially I'll need a much more general solution, that generates:
… and can go in the reverse (back to Swagger from changes in models and/or routes)
PS: My Blueprint
s are quite different now, as I'm using bottle
with separate a different "api" in each directory, e.g.: user_api
, profile_api
, auth_api
, friends_api
.
wonderful!~~
So.. was this merged in?
Not yet.
I think there will be many challenges in translate JSON schema to SQLAlchemy model, there is a project alchemyjsonschema which can convert SQLAlchemy model to JSON schema as a reference.
SQLAlchemy model needs to know which property is the primary key, and which is the index, in some cases, we don't want to expose some properties in a model, or expose some model. Those problems may resolve with the x-
property in Swagger for extending same database concepts.
First of all, thanks for the great project. It is very useful.
Most likely people using this generator is at the early stage of the project. At that time, all codes are overridable. :-)
Seems like all files under /api are non-overridable. If that is the case, why not making another folder "/db", put db related operation there. Some argument can add to let user select skip or upgrade or override.
Just 2 cents.
I've been working on an SQLalchemy branch.
Do you want me to form a pull-request out of it?