Open saurabhnanda opened 1 year ago
Yes this maybe usefull for quick n' dirty jobs where you don't want to make a dedicated table for the job to writeout in.
Good to see you back :)
I left supercede, @RiugaBachi may also wish to comment.
Folks, this has a breaking change in the library's external API. Is everyone largely fine with this?
@jappeace @tfausak @tchoutri
(please tag other active users, as well)
No objection on my part
Is there a way you could implement this without breaking existing code?
I see why this is useful. My team wouldn't necessarily benefit from it, so I could take or leave this change.
Any change to the schema of the job table is unfortunate. However adding a new optional column is about as low impact as you can get.
I would appreciate a non-breaking release before any breaking change. We've been using a source-repository-package
(rather than a Hackage release) for a while now.
@jappeace @tfausak one way to not break any existing code would be to have a build-time flag along with liberal use of CPP at the following places:
OddJobs.Types.Job
data type to add two extra fields if the CPP flag has been set. Two fields will be added if this flag is set:
jobResult
jobParentId
saveJobQuery
& saveJobIO
& runJob
defaultDelayedJobDeletion
(added in #106 ), to ensure a child job is deleted only along with its parentis there any other way to do this? and if CPP is the only way, when do we get finally get rid of the CPP?
I was thinking along the lines of: instead of changing this function in place, we add a new one and see if it can be made compatable, however I'm not sure if it's possible.
I'd not go the CPP/flag route as that incurs a rather troublsome maintenance burden and rather do the breakage.
I was thinking along the lines of: instead of changing this function in place, we add a new one and see if it can be made compatable,
@jappeace I think two versions of functions can still be dealt with, but what do you think about the Job{..}
data type?
Does anyone use the Job{..}
constructor in their application code? For creating a job if everyone is using the createJob
function, then adding optional/nullable fields to Job{..}
should not be. a problem...
I think the two DB columns that all users of the library are going to be forced to create are a greater problem than the Haskell code.... any ideas on how to tackle this?
@tchoutri @jappeace @tfausak what do you feel about the current attempt on making this backward compatibly and purely opt-in?
@jappeace @ivb-supercede any thoughts on this functionality / feature? Few notes: