updated db creation flow

[ArnabChatterjee20k]

No description provided.

[greptile-apps]

Greptile Summary

This PR introduces a provisioning → ready / failed status lifecycle for databases during Appwrite-to-Appwrite migrations, addressing a series of edge cases flagged in previous reviews around stuck databases, partial-failure recovery, and orphan cleanup ordering.

• Adds provisioningDatabases tracking in Destinations/Appwrite, calls markProvisionedDatabasesReady() before cleanupOverwriteOrphans(), and wraps per-database status flips in best-effort try/catch so one transient failure doesn't strand the rest.
• Forces SchemaAction::Overwrite for any database left in status=failed, recreates the missing backing collection when absent, and adds the database to the provisioning sweep in both the Skip (recovery) and Overwrite paths.
• Extends the Database, DocumentsDB, and VectorsDB resource models to carry the status field, and adds supportsDatabaseStatus() to the Source base class (overridden to true only for SOURCE_DATABASE Appwrite sources).

Confidence Score: 5/5

Safe to merge — all previously flagged edge cases are addressed and the new status lifecycle is correctly gated, ordered, and best-effort where appropriate.

The provisioning/ready/failed lifecycle is implemented end-to-end: status is set before collection creation, flipped to ready only after all resources transfer, per-database failures in the sweep do not strand siblings, and failed databases are recovered rather than skipped forever.

No files require special attention.

Important Files Changed

Filename	Overview
src/Migration/Destinations/Appwrite.php	Core change: adds provisioning/ready/failed lifecycle, markProvisionedDatabasesReady, setDatabaseStatus, markDatabaseFailed, collection-recreation on failed overwrite, and setPreserveDates scoping for database creation. All previous review concerns addressed.
src/Migration/Resources/Database/Database.php	Adds databaseStatus constructor parameter, fromArray mapping from status, toArray serialization, and getDatabaseStatus() getter. Clean, consistent change.
src/Migration/Resources/Database/DocumentsDB.php	Mirrors the parent Database change by passing databaseStatus from array status in fromArray. Consistent with the base class.
src/Migration/Resources/Database/VectorsDB.php	Same as DocumentsDB: adds databaseStatus to fromArray. Consistent with sibling classes.
src/Migration/Source.php	Adds default supportsDatabaseStatus() returning false to the base Source class - clean extension point.
src/Migration/Sources/Appwrite.php	Adds getSourceType() and overrides supportsDatabaseStatus() to return true only for SOURCE_DATABASE - correctly gates status lifecycle to database-backed Appwrite sources.

_{Reviews (15): Last reviewed commit: "updated" | Re-trigger Greptile}

[ArnabChatterjee20k]

@greptile
The provisioning lifecycle logic is structurally sound, but setPreserveDates(false) is applied unconditionally in importDatabaseResource for all database types regardless of source, silently dropping original creation timestamps across every migration type.

The setPreserveDates(false) override fires for Firebase, MySQL, and Appwrite API source migrations as well as the SOURCE_DATABASE path. Before this PR, the outer import() loop held setPreserveDates(true) so that explicitly-set $createdAt/$updatedAt values were honoured. Now those values are discarded for every database creation or overwrite, meaning users migrating from any source will see today's date instead of the original database creation date on the destination.

src/Migration/Destinations/Appwrite.php — the importDatabaseResource switch case where setPreserveDates(false) is set without a source-type guard

this is totally fine as we want this only to point to the latest date instead of the old present backup date for the database

[greptile-apps]

Got it, that's a valid intentional choice — using the current date on the destination makes sense when the goal is to track when the database was provisioned rather than when the source backup was created. I'll withdraw the concern.

Tip: You can customize Greptile's behavior for this repo with .greptile/rules.md and .greptile/config.json.

[abnegate]

Let's use a partial update here

[ArnabChatterjee20k]

backups doesn't inherit the Appwrite source and Appwrite source only take the source as api or databse
so added this support method so that it can be overriden
Backups inherit the source