Skip to content

Support for database clone operations#136

Draft
sl-at-ibm wants to merge 4 commits into
datastax:mainfrom
sl-at-ibm:SL-clone-support
Draft

Support for database clone operations#136
sl-at-ibm wants to merge 4 commits into
datastax:mainfrom
sl-at-ibm:SL-clone-support

Conversation

@sl-at-ibm

@sl-at-ibm sl-at-ibm commented Jun 23, 2026

Copy link
Copy Markdown

This PR adds support for database self-service clone operations to the SDK.

To do so, two new clients are introduced, to which the main DbOpsClient delegates:

  1. DbSnapshotClient, for snapshot-related actions (list snapshots)
  2. DbCloneClient, for clone-related actions (initiate clone and, later, inspect the status of a clone operation)

The snapshot client only allows listing the snapshots for the current DB (with or without filter parameters).

The clone client offers methods to:

  • initiate a clone into the current DB from another DB and one of its snapshots
  • inspect the status of an already-started clone into the current DB, given its Operation ID.

The reason to keep these two as separate clients is that the snapshots are focused on the source DB (hence you create the client pointing at that DB), while the clone (+get status) essentially forget about the source and work "on" the target DB. So for a full clone interaction the user would have to spawn two DbOpsClient instances, true, but for a good reason (to keep their mind organized around how the two DB do what).

Testing and such

Clone, right now, is testable mostly on DEV. (and even there, it often fails...)

So this PR also extends the general fixtures in AbstractDevopsApiTest.java to ensure DEV is properly targeted - this was needed by me in order to launch some tests.

The PR adds three tests, which however are probably not becoming ordinary tests that one runs frequently! They require quite some setup and some configuration (some of it, currently hardcoded in the test functions - let's see what should happen). My main goal was to see them working, it can then be decided later what to do of those.

some trouble with me building/testing

Note: not impacting the PR itself.

Right now, I could not properly build the repo with skipTests=true and succeed in later running a single test. Probably my limited knowledge. (note I did not commit this pom change to this PR.)

I could not run the tests at all unless I changed the pom to say, <skipTests>false</skipTests>, so that I could later run e.g.

mvn -X surefire:test -pl astra-sdk-devops -Dtest=DatabaseClientTest#shouldGetCloneStatusByOperationId

But without skipping the tests, the build process (mvn clean install -DskipTests=true) would try to run the tests each time, despite the command-line flag.
So I Ctrl-C'd out of the build process as soon as the tests started (ahem, not very elegant, I know. Likely one can do better).

@clun clun left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

Nice and clean.

You also inegrated the environment support getEnvironment(), great.

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants