search

ceph / paddles

RESTful API to store (and report) on Ceph tests
14 stars 26 forks source link

models: add issue_urls / comment jobs fields #66

Closed ghost closed 8 years ago

ghost commented 8 years ago

For the user to fill.

Signed-off-by: Loic Dachary loic@dachary.org

ghost commented 8 years ago

I guess there is a way to automate the creation of the matching paddles/alembic/versions/ files ?

zmc commented 8 years ago

What about using a generic issue_urls field ?

ghost commented 8 years ago

@zmc good idea :-) modifed & repushed, thanks for the quick review !

alfredodeza commented 8 years ago

If the model is getting extended to accommodate a new set of information, it seems that a field name like:

issue_urls

Could actually be split into an Issue model and a url field. This would also align better with the comments field which could be strictly related to a specific issue but could also allow non-issue-related comments to be added.

Since it looks like these changes want to relate a job to potentially multiple issues, a one-to-many relationship might be good here. This would look like:

>>> job.issues
[<issue 1>, <issue2>]

Each one of those issues could hold information for urls, comments, and anything extra.

ghost commented 8 years ago

@alfredodeza let's keep it simple for now. I'd rather have a field with a single URL than adding more structure before we can refine the use case. In practice we (stable release team) have not used more than one issue per job.

alfredodeza commented 8 years ago

@dachary if it is a single issue url then issue_urls (a plural) is a misnomer.

Adding a second model object is super simple and offers future flexibility which is favorable to have as an available option. The current approach would not allow future expansion or any kind of flexibility.

Maybe I am not understanding where you think the complexity is?

ghost commented 8 years ago

@alfredodeza I've repushed with issue_url instead of issue_urls. We have a use case for a single URL, not for multiple URLs. I'd rather stick to the use case rather than create something for which there is no use right now.

ghost commented 8 years ago

ping ?

zmc commented 8 years ago

I agree with @dachary; if we have a need for more information beyond a single issue URL, we can move toward a one-to-many relationship with Job and Issue in the future, much like we do with Job and Node.