search

taddison / tsqlScheduler

Create and monitor agent jobs & execution from tables
MIT License
3 stars 0 forks source link

Use a custom file extension to identify jobs stored as files #48

Closed taddison closed 6 years ago

taddison commented 6 years ago

Currently they are .json, and so if you were to mix them with any other .json files in the same folder you'd have a hard time figuring out which ones were jobs. You could load them and look for a property to help you out, but I think we might make things easier if the convention was to store all jobs as .job.json.

I don't think this requires much/any changes.

@petervandivier - thoughts?

petervandivier commented 6 years ago

Agree - not least because we’ve already encountered trouble between requiring the file name to be a parseable element in the file for deployment. Not sure what the optimal solution is off the bat. Suppose it depends if we’re aiming to solve an existing problem or tidy the design?

taddison commented 6 years ago

Looking at where this change would be made, I don't think there is any work to be done apart from the readme. I'll add in a PR (though I think .task.json is a better extension than .job.json!).

When it comes to changing the files to understand the convention, I think there is probably a split required - what I think we'd want is some new commands that you can glue together into the current form:

Read-TSConfigFromFile -Path $filePath | Publish-TSTask -Server $server -Database $database

The publish command only works with 'fully baked' config files, and we've then also got support for flows like Read-TSTaskFromDatabase ... | Publish-TSTask.

taddison commented 6 years ago

And yes I'm wondering about some kind of naming convention as Publish-Task and Read-Task seem super-generic? Another issue...