feat: enhance JobHistoryInfo with Task Details and Compatibility Improvements

[BaiMoHan]

Summary:

This PR introduces new detailed information regarding tasks within the JobHistoryInfo class. Specifically, I've added tracking for three key timestamps related to tasks in the queue: in_queue_mills, start_mills, and finish_mills. This data will be recorded in the database for historical query purposes, benefiting clients by facilitating data analysis and enabling optimization of call frequency control.

Key Changes:

1. Task Timing Information:

Added fields to capture in_queue_mills, start_mills, and finish_mills for tasks in the queue. Implemented storage of this data in the database to support historical queries.

2. Backward Compatibility:

To ensure compatibility with previous versions, I've implemented a migration process that updates the table structure on the initial startup of the new version. This allows existing data to be retained and prevents any loss of information. Bug Fix in Job History API:

Addressed an issue with the /v1/generation/job-history API endpoint, where filtering by job_id did not return a single record as expected. The filtering mechanism has been improved to ensure accurate results.

3. API Compatibility: Since the changes involve adding new fields without altering the existing API structure, I chose to enhance the current API rather than upgrading it to v2. This allows clients using older versions to seamlessly transition to the new API without needing extensive modifications to their existing code.

Testing

Feel free to make any adjustments or let me know if you need further changes!

[mrhan1993]

It's hard work 🙇‍♂️, but 2.5 adds a lot of parameters. I have a headache looking at this now. At the beginning, I divided every attribute into pieces and stored it, but now I feel like I have dug a hole for myself. So in another project, everything was put in one field and saved as Json

[BaiMoHan]

It's hard work 🙇‍♂️, but 2.5 adds a lot of parameters. I have a headache looking at this now. At the beginning, I divided every attribute into pieces and stored it, but now I feel like I have dug a hole for myself. So in another project, everything was put in one field and saved as Json

Perhaps we could consider redesigning the database structure. The field of AI-generated images is fundamentally different from typical e-commerce domains; it does not involve complex conditional queries beyond pagination. The parameters and metadata related to image generation can be stored as archival data, so we could consider storing the generation parameters as a database field in the form of a JSON string. This approach would alleviate concerns about frequent changes to the table structure due to the evolving image generation algorithms.

Additionally, we could store the type of generated image, such as text-to-image or image-to-image, allowing us to perform corresponding JSON parsing based on this type. Other fields, such as task-related data, which are essential for our API service, can continue to iterate and optimize over time. This way, we can continuously follow and integrate changes from the upstream image generation algorithms while also enhancing the overall robustness of our service in response to downstream calls.

[mrhan1993]

@BaiMoHan I think I should use the refactoring of another project here. The async_worker changes are too much trouble to change.

[BaiMoHan]

@BaiMoHan I think I should use the refactoring of another project here. The async_worker changes are too much trouble to change.

Now, not very many developers use the FooocusAPI, so refactoring FooocusAPI may be easier. I am not sure about the difficulty of merging the upstream changes. It may take some time for me to figure this out.

[BaiMoHan]

What is the problem with FooocusAPI? I took a glance at its API documentation, and it contains more details than this. I haven't run it.

[mrhan1993]

I can simply delineation Fooocus Fooocus-API Fooocus API in the work of the difference

Exclude model inferencing only focus on the parameter part, all parameters will eventually be summarized in async_worker.py

Fooocus collects these parameters through the WebUI, and then these parameters are passed to the async_worker, where they are instantiated as a task object. In addition, most parameters will be decomposed here, and these tasks will be processed through a loop and a list. Before 2.5, this file had almost only one function. After 2.5, it was decomposed for many methods, and the processing method of parameters was changed. The task class was also overridden. However, its processing logic has not changed, just changed the way

Fooocus-API also uses "async_worker.py" for task processing, but some changes have been made, this file is copied to the "worker.py", the most important change is to use its own task queue/override the task return method, although it seems not much, but the latest "async_worker.py" has exceeded 1500 lines, it is not very easy to merge them

I gave up my own task queue on the Fooocus API and focused on processing the incoming parameters and processing the task results of the Fooocus. The core logic is simplified to convert the parameters to the format required by the async_worker.py and convert the returned results to the required format. It can be merged into the main Fooocus line, even if it is not merged, oh that update_branch can complete most updates

You should be able to see that so many interfaces are actually unnecessary, for async_worker.py it will get the same number of parameters for either generation.

I plan to refactor the Fooocus-API after it completes the 2.5 update, using the logic of the Fooocus API. In theory, it can be fully compatible with existing interfaces. I can also have more time to improve the documentation.

a more question, are you chinese?

[BaiMoHan]

I can simply delineation Fooocus Fooocus-API Fooocus API in the work of the difference

Exclude model inferencing only focus on the parameter part, all parameters will eventually be summarized in async_worker.py

Fooocus collects these parameters through the WebUI, and then these parameters are passed to the async_worker, where they are instantiated as a task object. In addition, most parameters will be decomposed here, and these tasks will be processed through a loop and a list. Before 2.5, this file had almost only one function. After 2.5, it was decomposed for many methods, and the processing method of parameters was changed. The task class was also overridden. However, its processing logic has not changed, just changed the way

Fooocus-API also uses "async_worker.py" for task processing, but some changes have been made, this file is copied to the "worker.py", the most important change is to use its own task queue/override the task return method, although it seems not much, but the latest "async_worker.py" has exceeded 1500 lines, it is not very easy to merge them

I gave up my own task queue on the Fooocus API and focused on processing the incoming parameters and processing the task results of the Fooocus. The core logic is simplified to convert the parameters to the format required by the async_worker.py and convert the returned results to the required format. It can be merged into the main Fooocus line, even if it is not merged, oh that update_branch can complete most updates

You should be able to see that so many interfaces are actually unnecessary, for async_worker.py it will get the same number of parameters for either generation.

I plan to refactor the Fooocus-API after it completes the 2.5 update, using the logic of the Fooocus API. In theory, it can be fully compatible with existing interfaces. I can also have more time to improve the documentation.

a more question, are you chinese?

Thank you for your explanation. It's a great idea. What we may need to do is to build many adapters between the custom data objects and Fooocus data objects. Also, we can learn from the sd-web-ui API. Yes, I can speak Chinese. Next week, I will pay more attention to understanding the code of the three repositories.

[BaiMoHan]

The additions to the Foooocus API on top of Fooocus are very concise and independent. I believe that the Foooocus API is a good secondary development project that separates the API from the diffusion model, making it easier to update the diffusion model logic and improve the API. If we apply the logic pattern of Foooocus API to Fooocus-API, the two projects will evolve into the same project, is this what we expect? If the final integration models of both are the same, then we can focus on the development of Foooocus API and provide migration instructions for the two projects. If they still remain separate, we need to consider the advantages of Foooocus-API over Foooocus API. If it's just about the differences in API, we can currently generate client SDK through swagger-gen.

The integration and construction of the sd-api are in line with the thinking behind the Foooocus API. https://github.com/AUTOMATIC1111/stable-diffusion-webui/blob/82a973c04367123ae98bd9abdf80d9eda9b910e2/modules/api/api.py#L530

[mrhan1993]

For me, the biggest difference is the difficulty of maintenance. Apart from the differences in parameters, I think these two projects are basically no different for users. My original idea was to stop the maintenance of Fooocus-API and migrate to Fooocus-API, but the Fooocus-API project has more users. So I'm not sure which is better.