Risposta diretta: La migrazione da ESX a QBCore è una riscrittura controllata e una migrazione dati, non un cambio di framework. Crea un server di staging QBCore pulito, inventaria ogni dipendenza ESX, definisci una mappa dati esplicita campo per campo, porta le risorse contro gli attuali API, prova il rollback e procedi solo dopo che i controlli referenziali e di gameplay sono superati.
Cosa deve essere mappato
| Superficie | Decisione di migrazione | Prova di accettazione |
|---|---|---|
| Identità del giocatore | Mappa gli identificatori legacy e i personaggi agli ID cittadini QBCore senza collisioni. | Ogni giocatore campionato si risolve in un record del personaggio previsto. |
| Denaro e conti | Mappa ogni account esplicitamente; non dare per scontati nomi o semantiche uguali. | I totali pre/post si riconciliano per un campione bloccato. |
| Lavori e gradi | Definisci una mappatura per ogni lavoro e grado attivo, inclusi i fallback per i disoccupati. | I flussi di permessi e pagamenti corrispondono alla mappa approvata. |
| Oggetti e inventario | Mappa nomi, metadati, peso, slot e proprietà di archiviazione. | Nessun nome di oggetto orfano; gli inventari persistono dopo la riconnessione. |
| Veicoli e proprietà | Normalizza le chiavi di proprietà, le targhe, i garage e i campi di stato. | I record di proprietà rimangono unici e accessibili. |
| Risorse personalizzate | Sostituisci le callback, gli eventi e i player API di ESX con gli equivalenti documentati di QBCore. | Ogni flusso di risorse end-to-end passa in staging. |
Sequenza di migrazione
- Blocca le modifiche allo schema e alle risorse; effettua un backup ripristinabile del database e dei file.
- Crea QBCore dalla sua ricetta o repository mantenuto in un ambiente di staging isolato.
- Esporta un inventario dello schema e scrivi una mappatura versionata per identità, account, lavori, oggetti, veicoli e tabelle personalizzate.
- Rendi le trasformazioni idempotenti ed eseguile solo su una copia del database usa e getta.
- Porta le risorse una alla volta utilizzando la documentazione attuale di QBCore; non fare affidamento sulla sostituzione cieca dei nomi degli eventi.
- Riconcilia conteggi di righe, unicità, somme e riferimenti orfani, quindi esegui gameplay, riconnetti ed esegui test di riavvio.
- Prova il rollback. Durante il cutover, interrompi le scritture, esegui un backup finale, riesegui il processo collaudato e verifica prima di riaprire le join.
Non copiare un modello SQL generico
Gli schemi ESX e QBCore variano in base a release, ricetta, inventario e risorse personalizzate. Una generica istruzione CREATE TABLE o INSERT può scartare silenziosamente metadati o creare valori predefiniti non validi. Deriva lo schema di migrazione SQL dai due schemi effettivamente installati, rivedi i vincoli e conserva una mappa di identità legacy-to-new per supporto e audit.
Ambito e limitazioni
Questo è un piano di controllo della migrazione, non uno schema SQL eseguibile per un server sconosciuto. Non stima ore né promette una conversione senza perdite. Le risorse crittografate o in deposito potrebbero non essere portabili. Controlla le licenze, i framework API correnti e i diritti di migrazione di ogni pacchetto prima che inizi il lavoro.