Skip to content
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

[Feature] findUpdatedScenes #870

Open
ikmckenz opened this issue Dec 21, 2024 · 4 comments
Open

[Feature] findUpdatedScenes #870

ikmckenz opened this issue Dec 21, 2024 · 4 comments
Labels
enhancement New feature or request

Comments

@ikmckenz
Copy link
Contributor

Opening up discussion on a findUpdatedScenes API, first described in stashapp/stash/issues/2903. Original author @mmenanno described it as follows:

Stash-Box Backend Side

For the sake of making the process optimal Stash-Box should have a new query findUpdatedScenes that takes an array of SceneUpdateInput structured something like:

{
  "scene_id": "stash_id",
  "last_recorded_update": "external_updated_at"
}

This call can return a updated Boolean, deleted Boolean, and Scene object for each input.

  • If the last_recorded_update is NOT older than the updated_at on the scene_id, it will return updated: false , deleted: false, and no scene object

  • If the last_recorded_update is older than the updated_at on the scene_id but the scene has been deleted, updated: true, deleted: true, and no scene object

  • If the last_recorded_update is older than the updated_at on the scene_id and the scene is not deleted, updated: true, deleted: false, and the updated Scene object

To me maybe this seems to do too much on the stash-box backend, perhaps the input would be better as the list of stash_id's and the response could be the stash_id's and their last updated time, leaving the identification of more recently scenes to the local stash application. This also seems to mirror what @stg-annon was saying. Curious to hear people's thoughts.

@ikmckenz ikmckenz added the enhancement New feature or request label Dec 21, 2024
@stg-annon
Copy link

aside from publishing something like a list object ids and last modified timestamps, Id think the only thing we could maybe use on the sash-box side of things is a findScenes query that takes a list of IDs so you don't have to make a query for each scene to check if its been updated you could do it page by page

also adding a some kind of date modified field directly to objects that just takes the last accepted edit closed date and applies it to the object would help with not having to query a list of edits and just the main object and this field

@ikmckenz
Copy link
Contributor Author

aside from publishing something like a list object ids and last modified timestamps

Just to put some pen to paper here I opened draft PR #871, which does this. But I also see the merits of just having the less-specific findScenes API as well.

@InfiniteStash
Copy link
Collaborator

aside from publishing something like a list object ids and last modified timestamps

Just to put some pen to paper here I opened draft PR #871, which does this. But I also see the merits of just having the less-specific findScenes API as well.

Appreciate the PR, but at a glance this looks like a micro-optimization of findScenes and I'd rather avoid the maintenance burden of a duplicate endpoint unless there's major performance gains.

I'd be interested in seeing an findUpdatedScenes endpoint. While it's slightly more work for the backend, I think it would be useful to be able to fire off a single query and get scene data back rather than going back and forth multiple times.

@ikmckenz
Copy link
Contributor Author

ikmckenz commented Dec 31, 2024

Opened up PR #878 with the described findUpdatedScenes API. It ignores invalid passed scene ids and so includes id in the response even if not updated or deleted. Testing locally it seems fine, but not sure how performance will be on a big instance.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants