stash icon indicating copy to clipboard operation
stash copied to clipboard

Add interfaces to destroy file database entries

Open WithoutPants opened this issue 1 month ago • 0 comments

Describe the feature you'd like

There is currently no graphql-supported way to destroy file database entries. Historically, this has been because it was internally managed by the scan and clean subsystems. There are cases however where it is necessary to be able to destroy file entries. For example, when deleting a scene, we can set a flag to delete the file or not. When the file is not selected to be deleted, the file entry remains in the database, and a scene is created from the file on the next scan. Deleting the file removes the entry in the database, but it also deletes the file on the file system.

Proposal is to add the following interfaces to the graphql schema:

mutation {
  "destroy file entries in the database without deleting files from the filesystem. Files must not be assigned to objects."
  destroyFiles(ids: [ID!]!): Boolean
}

The XDestroyInput inputs should also be updated to add the following fields:

"If true, destroy the associated file entry from the database if the file is not assigned to any other objects."
destroy_file: Boolean

It is expected that these interfaces will only be used in the graphql playground for data correction purposes. I don't anticipate a need to include them in the UI, unless it is via an advanced user interface.

Describe the benefits this would bring to existing users

The necessity for this is mostly for data correction for circumstances where file entries are corrupted on some way. An example of this is #6326 where corrupt file entries will be created for files that have been renamed with a different case on filesystems with case-insensitivity.

Is there an existing way to achieve this goal?

Manually deleting the file entries in the database via the execSQL interface or via an sqlite tool.

Have you searched for an existing open/closed issue?

  • [x] I have searched for existing issues and none cover the core request of my proposal

Additional context

No response

WithoutPants avatar Dec 02 '25 02:12 WithoutPants

@saragluna @rujche why was there a bug fix release that released every library, put out for the old 5.x version?

mrm9084 avatar Dec 09 '25 17:12 mrm9084

Hi, @mrm9084

@saragluna @rujche why was there a bug fix release that released every library, put out for the old 5.x version?

This release is used to fix this bug: https://github.com/Azure/azure-sdk-for-java/issues/47285#issuecomment-3625685516

And we always keep all the Spring Cloud Azure libraries have the same version.

rujche avatar Dec 10 '25 01:12 rujche

Closing this PR because the release/spring-cloud-azure_5.24.1 branch will not be used any more.

rujche avatar Dec 15 '25 02:12 rujche