search

crs-tools / tracker

CRS Ticket Tracker
Apache License 2.0
18 stars 11 forks source link

Resetting tickets (and their children) #188

Closed j-licht closed 5 years ago

j-licht commented 6 years ago

For our use case, it's useful to have resetTicket methode in the API. To allow re-encode a video without re-creating the encoding ticket. The reset should set a ticket back to its initial state. So after that commenceState has to be called to get things happen again. When resetting a meta ticket all encoding childs should also be reset. When resetting a 'master' encoding ticket, all tickets of a depending profile should be reset too.

Do we implement this as a model function or stored procedure?

saerdnaer commented 6 years ago

Are you aware of the the following feature – you might be able to reuse it for your goals

image
jjeising commented 6 years ago

Do we implement this as a model function or stored procedure?

Currently we have Ticket::resetSource, which does some similar things, but is very specific.

For consistency and transactional reasons I think this should be moved to a stored procedure, which should also support a desired state for the recording ticket (exact state, first state before or first state after, if there are none before) and maybe even for the encoding tickets.

j-licht commented 6 years ago

For consistency and transactional reasons I think this should be moved to a stored procedure, which should also support a desired state for the recording ticket (exact state, first state before or first state after, if there are none before) and maybe even for the encoding tickets.

What did you mean with before and after? Before which thing or state?

In our use case recording tickets doesn't matter, therefore I'm not sure how to handle them.

jjeising commented 6 years ago

What did you mean with before and after? Before which thing or state?

As arbitrary states can be disabled per project the target (to reset to) state has to computed from a desired hardcoded state. Example: desired state for reset is ready to encode, if it is disabled, the next state after should probably be selected. I first thought about resetting to the previous state for disabled states, but this wouldn't be helpful.

pegro commented 6 years ago

How would you provide these desired states for different ticket types to a stored procedure? Having explicit parameters for each type? So we'd have to extend the API every time (although it didn't happen for a long time) we add a ticket type?