Skip to content

SOLR-18358: remove the non-incremental (full-snapshot) backup path - #4808

Open
serhiy-bzhezytskyy wants to merge 2 commits into
apache:mainfrom
serhiy-bzhezytskyy:SOLR-18358-remove-full-snapshot-backup
Open

SOLR-18358: remove the non-incremental (full-snapshot) backup path#4808
serhiy-bzhezytskyy wants to merge 2 commits into
apache:mainfrom
serhiy-bzhezytskyy:SOLR-18358-remove-full-snapshot-backup

Conversation

@serhiy-bzhezytskyy

Copy link
Copy Markdown
Contributor

https://issues.apache.org/jira/browse/SOLR-18358

Removes CollectionAdminRequest.Backup.setIncremental(boolean) and the incremental=false ("full snapshot") backup path in BackupCmd, plus the commitName/snapshotName fields on Backup and the v2 REST request body -- commitName was only ever read inside the path being removed.

SnapShooter's own, separate commitName handling (the core-level BACKUPCORE action) is untouched -- checked, it has zero dependency on incremental, it's an independent capability outside this ticket's scope. CoreAdminParams.COMMIT_NAME is kept, since it's shared with the snapshot admin actions (CREATESNAPSHOT/etc).

BackupRestoreApiErrorConditionsTest's legacy-format-rejection test now builds its on-disk fixture by hand (can't create one via the removed API anymore); everything else is a straight collapse of if (incremental) branches.

Related, and in tension with this PR: #4807 (SOLR-18403) fixes bin/solr snapshot-export to correctly use commitName+incremental=false -- the exact capability this PR removes. If both land, #4807's fix becomes moot. Flagging for whoever reviews either one; not resolving the sequencing here.

AI-assisted (Claude Sonnet 5)

Removes CollectionAdminRequest.Backup.setIncremental(boolean) and the
incremental=false branch it controlled in BackupCmd, plus the orphaned
commitName/snapshotName fields on Backup and the v2 REST request body
(commitName was only read inside the deleted path). SnapShooter's own,
separate commitName handling is untouched -- verified it has zero
dependency on incremental, it's an independent BACKUPCORE capability.
CoreAdminParams.COMMIT_NAME kept -- shared with the snapshot admin
actions. Test fixture for the legacy-format rejection test now built by
hand on disk instead of via the removed API.

@epugh epugh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was expecting more changes in the Ref Guide, not jsut a not or two.. or more of an API to be deleted!

Solr can still restore from backups that use this old format, but creating new backups of this format is not recommended and is officially deprecated.
See the `incremental` parameter below for more information.
Previous versions of Solr supported creating a different, non-incremental backup file format that lacked the incremental support described above.
That format can no longer be created, but Solr can still restore from backups that already use it.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

is this something we would want to keep long term? Or is it a temporary thing?

Provided as a query parameter for v1 requests, or as a path segment for v2 requests.
+
For incremental backups, the backup name should be reused to add new backup points to the existing backup. For non-incremental backups (deprecated), this name is checked to ensure it doesn't already exist, and an error message is raised if it does.
The backup name should be reused to add new backup points to the existing backup.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should this be rephrased as "The name of the backup to use"?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants