-
Notifications
You must be signed in to change notification settings - Fork 23
Implement job queues for desktop dive #1534
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
a26ed0a
df10132
fb4e83b
78ea7d0
ff5041f
52c692b
55c3626
b9ce509
ae365a1
0747d5c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -184,11 +184,33 @@ export interface RunTraining { | |
| }; | ||
| } | ||
|
|
||
| export type JobArgs = RunPipeline | RunTraining | ExportTrainedPipeline | ConversionArgs; | ||
|
|
||
| export function isRunPipeline(spec: JobArgs): spec is RunPipeline { | ||
| return 'datasetId' in spec && 'pipeline' in spec; | ||
| } | ||
|
|
||
| export function isExportTrainedPipeline(spec: JobArgs): spec is ExportTrainedPipeline { | ||
| return 'path' in spec && 'pipeline' in spec; | ||
| } | ||
|
|
||
| export function isRunTraining(spec: JobArgs): spec is RunTraining { | ||
| return ( | ||
| 'datasetIds' in spec | ||
| && 'pipelineName' in spec | ||
| && 'trainingConfig' in spec | ||
| ); | ||
| } | ||
|
Comment on lines
186
to
+203
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just wondering if for simplicity sake we make a base Type of JobArgs that the other items extend and that base type has a 'type' that is a string value and each subsequent type implements a type as Might make it easier to add new types and no have these functions that are relying on multiple arguments to determine the type? |
||
|
|
||
| export interface ConversionArgs { | ||
| meta: JsonMeta; | ||
| mediaList: [string, string][]; | ||
| } | ||
|
|
||
| export function isConversion(spec: JobArgs): spec is ConversionArgs { | ||
| return 'meta' in spec && 'mediaList' in spec; | ||
| } | ||
|
|
||
| export interface DesktopJob { | ||
| // key unique identifier for this job | ||
| key: string; | ||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@BryonLewis this feels like the most controversial part of the change. Previously the conversion job was kicked off deep within the
finalizeMediaImportcode path. With my proposed change, I'm no longer starting a job here.Consuming code that needs to finalize an import is responsible for starting the conversion job (which it can do by inspecting the
mediaListto see if there are any files that need to be converted). To me it looked likeRecent.vuewas the place where this is happening, so there are changes in that file that queue conversion jobs based on the result of the finalization process.I'd love to hear your thoughts on this. If we don't want to make a big structural change like this I can revert the associated changes and keep the status quo for conversion jobs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've been looking at the PR and I think I'm fine with that. Both the BatchImport and others use Recent.vue for the finalizeImport and having that be responsible for job creation seems to be fine.