Allow users to name jobs about appengine-pipelines

[aozarov]

Yes, the intent was for one to override getJobDisplayName for returning a value which is different from the default. From a user perspective a Job is immutable but this setter violates that (and in an inconsistent way - only going to have an effect upon Job submission). Also, by overriding (vs setter) one could make the value more "dynamic".

[billy1380]

In theory what you are saying is correct; in practice I have 10s of jobs/job classes. For all of them I have to override getJobDisplayName that requires me to add a member variable called name to each, then add a setter and/or a constructor to set that name for the job on creation.

Now that sounds tedious, right... I should have a parent class that I inherit from which has that behaviour, except that I am mandated by the framework to inherit from Job. The alternative is for me to Have a set of superclasses called something like NamedJob or something that extends each of the 6 types of Job<>.

As for the immutability of the Job, again that should be true, however, every change of status that requires the persistence of a job instance re-saves the display name. So even though I have no intention of changing the display names of jobs, the design does not reflect that requirement at least not when it comes to the display name.

[aozarov]

I don't think any change of job status (or retries) re-persist the job instance. Job information such as status is handled/saved-by JobRecord and the instance is saved by JobInstanceRecord. The former gets updated between invocations and status change but (AFAIK) not the latter.
Also, one should consider calls to setDisplayName on a JobRefernce after job was submitted...
I understand your pain but feel that for a typical use-case overriding (a method or a base-class) would be sufficient. I think the correct approach for providing a better support for display-name would be to provide it as a JobSetting (save it similar to other JobSetting values and use it instead of getClass().getName() if JobRecord has a value for it).

[billy1380]

I really like the job setting idea. It fits really well. I will have a play and see what I can come up with. Any recommendations? Feel free to close/reject the previous pull request.

[aozarov]

No recommendation. Follow the path of existing JobSetting handling (shouldn't be too bad).

[billy1380]

:) Thank you