Skip to main content

Migration : Liaison Utilisateurs ↔ Données de Trading

📋 Vue d’ensemble

Ce document décrit la migration future pour lier les utilisateurs aux données de trading (exchanges, positions) une fois que l’authentification sera stabilisée.

🔄 Changements à effectuer

1. Modèle User

model User {
  id            String    @id @default(auto()) @map("_id") @db.ObjectId
  email         String    @unique
  emailVerified Boolean   @default(false)
  name          String?
  image         String?
  createdAt     DateTime  @default(now())
  updatedAt     DateTime  @updatedAt
  
  // Relations Better Auth
  accounts      Account[]
  sessions      Session[]
  twoFactor     TwoFactor[]
  organizations OrganizationMember[]
  
  // Relations Trading (à réactiver)
  swingPositions swingPosition[]
  exchanges      exchange[]
}

2. Modèle exchange

model exchange {
  id            String         @id @default(auto()) @map("_id") @db.ObjectId
  name          String
  apiKey        String /// @encrypted
  apiSecret     String /// @encrypted
  password      String? /// @encrypted
  balanceTotal  Float?
  balanceFree   Float?
  type          ExchangeType
  isActive      Boolean        @default(false)
  
  // Relation User (à réactiver)
  userId        String?        @db.ObjectId
  user          User?          @relation(fields: [userId], references: [id])
  
  exchangePairs exchangePair[]
  symbolPairs   SymbolPair[]
}

3. Modèle swingPosition

model swingPosition {
  id                      String         @id @default(auto()) @map("_id") @db.ObjectId
  exchangePair            exchangePair   @relation(fields: [exchangePairId], references: [id])
  exchangePairId          String         @db.ObjectId
  
  // Relation User (à réactiver)
  userId                  String?        @db.ObjectId
  user                    User?          @relation(fields: [userId], references: [id])
  
  activity                Json? @default("[]")
  orderSide               OrderSide
  timeframe               Timeframe      @relation(fields: [timeframeId], references: [id])
  timeframeId             String         @db.ObjectId
  status                  PositionStatus @default(NEW)
  
  // ... reste des champs
}

🔧 Services à mettre à jour

AuthService.ts

// Méthode deleteUser à mettre à jour
async deleteUser(userId: string) {
  try {
    // Supprimer les positions de trading de l'utilisateur
    await this.prisma.swingPosition.updateMany({
      where: { userId },
      data: { userId: null }
    })
    
    // Supprimer les exchanges de l'utilisateur
    await this.prisma.exchange.updateMany({
      where: { userId },
      data: { userId: null }
    })
    
    // Supprimer l'utilisateur (cascade supprimera les sessions, accounts, etc.)
    await this.prisma.user.delete({
      where: { id: userId }
    })
    
    return true
  } catch (error) {
    console.error("Error deleting user:", error)
    throw error
  }
}

// Méthode getUserStats à mettre à jour
async getUserStats(userId: string) {
  try {
    const [swingPositions, exchanges, totalPnl] = await Promise.all([
      this.prisma.swingPosition.count({
        where: { userId }
      }),
      this.prisma.exchange.count({
        where: { userId }
      }),
      this.prisma.swingPosition.aggregate({
        where: { userId },
        _sum: { pnl: true }
      })
    ])
    
    return {
      swingPositions,
      exchanges,
      totalPnl: totalPnl._sum.pnl || 0
    }
  } catch (error) {
    console.error("Error getting user stats:", error)
    throw error
  }
}

📊 Migration des données existantes

Script de migration

// scripts/migrate-user-trading.ts
import { PrismaClient } from '@prisma/client'

async function migrateUserTrading() {
  const prisma = new PrismaClient()
  
  try {
    // 1. Créer un utilisateur par défaut pour les données existantes
    const defaultUser = await prisma.user.create({
      data: {
        email: '[email protected]',
        name: 'System User',
        emailVerified: true
      }
    })
    
    // 2. Lier les exchanges existants à l'utilisateur par défaut
    await prisma.exchange.updateMany({
      where: { userId: null },
      data: { userId: defaultUser.id }
    })
    
    // 3. Lier les positions existantes à l'utilisateur par défaut
    await prisma.swingPosition.updateMany({
      where: { userId: null },
      data: { userId: defaultUser.id }
    })
    
    console.log('Migration terminée avec succès')
  } catch (error) {
    console.error('Erreur lors de la migration:', error)
  } finally {
    await prisma.$disconnect()
  }
}

🚀 Étapes de déploiement

  1. Phase 1 : Stabiliser l’authentification
    • Tester toutes les fonctionnalités d’auth
    • Déployer en production
    • Valider avec les utilisateurs
  2. Phase 2 : Préparer la migration
    • Créer le script de migration
    • Tester sur un environnement de staging
    • Préparer le rollback
  3. Phase 3 : Exécuter la migration
    • Mettre à jour le schéma Prisma
    • Exécuter le script de migration
    • Mettre à jour les services
    • Déployer les changements
  4. Phase 4 : Validation
    • Tester les nouvelles relations
    • Valider les performances
    • Surveiller les erreurs

⚠️ Considérations importantes

  • Backup : Toujours faire un backup avant la migration
  • Rollback : Préparer un plan de rollback
  • Performance : Les requêtes avec relations peuvent être plus lentes
  • Indexes : Ajouter des index sur les champs userId
  • Permissions : Mettre à jour les permissions d’accès aux données

📝 Checklist de migration

  • Backup de la base de données
  • Test de la migration sur staging
  • Mise à jour du schéma Prisma
  • Exécution du script de migration
  • Mise à jour des services backend
  • Mise à jour des composants frontend
  • Tests de régression
  • Déploiement en production
  • Validation post-déploiement
  • Documentation mise à jour