feat(migration): create unique index on folders for parent_uuid and plain_name

[jzunigax2]

What

Create a new unique index folders_parentuuid_plainname_unique on the folders table using (parent_uuid,
plain_name) to replace the legacy folders_plainname_parentid_key index.

Why

1. Legacy index uses deprecated column

The current unique index folders_plainname_parentid_key uses parent_id (integer FK), while we have kept
migrating towards using parent_uuid (UUID FK) for all folder relationship operations.

-- Current (legacy)
CREATE UNIQUE INDEX folders_plainname_parentid_key
ON folders (plain_name, parent_id)
WHERE deleted = false;

-- New (aligned with application code)
CREATE UNIQUE INDEX folders_parentuuid_plainname_unique
ON folders (parent_uuid, plain_name)
WHERE deleted = false;

2. Suboptimal column order causing inefficient uniqueness checks

The legacy index has plain_name as the first column, which has low cardinality. This forces the db to possibly scan through entries before narrowing by parent.

The new index places parent_uuid first (high cardinality).

3. Application code already uses parent_uuid:

  // folder.repository.ts:397-414
  async findByNameAndParentUuid(
    name: FolderAttributes['name'],
    plainName: FolderAttributes['plainName'],
    parentUuid: FolderAttributes['parentUuid'],  // Uses UUID, not ID
    deleted: FolderAttributes['deleted'],
  ): Promise<Folder> {
    const folder = await this.folderModel.findOne({
      where: {
        [Op.or]: [{ name }, { plainName }],
        parentUuid: { [Op.eq]: parentUuid },
        deleted: { [Op.eq]: deleted },
      },
    });
    return folder ? this.toDomain(folder) : null;
  }

How

Migration uses CREATE INDEX CONCURRENTLY to avoid table locks:

  CREATE UNIQUE INDEX CONCURRENTLY folders_parentuuid_plainname_unique
  ON folders (parent_uuid, plain_name)
  WHERE deleted = false AND removed = false;

[sg-gs]

Running migration @jzunigax2

[github-actions]

This PR is stale because it has been open for more than 15 days with no activity.

[sg-gs]

This PR has conflicts with master @jzunigax2, let's reconcile it (waiting this before #883)

[github-actions]

This PR is stale because it has been open for more than 15 days with no activity.

[sg-gs]

Running migration

[sg-gs]

This index should include and removed = false also. Otherwise, permanently removed folders inside the a parent could prevent the same folder (=same name) creation inside. This could seem tricky but this could be a common case on a desktop sync if a rename happens, for instance.

[jzunigax2]

hmm it does seem tricky, this was meant to replace this other index which also only has a where deleted = false

by adding removed = false to the where wouldn't that prevent creaing a new folder with the same name as a trashed but not deleted one in the same parent? or am I missing something?

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud