Segnalazione #4
Segnalazione #1: Migrazione octomon a django
Mantenere storico dati
0%
Description
Bisogna mantenere lo storico dei dati. Per gli utenti si puo' passare ad usare la struttura di Django, visto che sono LDAP e sono pochi, ma tutti gli altri sono tanti dati.
Valutare se importarli dopo in una nuova struttura, oppure riciclare quella attuale, aggiornando solo la parte degli utenti.
ATTENZIONE: tanti dati sono legati agli utenti per ID, quindi bisognera' riallinearli.
Files
History
Updated by Mark Caglienzi over 11 years ago
- File octomonschema.sql octomonschema.sql added
- File inspectdb-models.py inspectdb-models.py added
- Assignee changed from Mark Caglienzi to Christopher R. Gabriel
Ieri ho fatto il dump del database dalla macchina di produzione e l'ho importato in un database MySQL in locale.
Ho estratto lo schema del db, ma c'è qualcosa che mi lascia qualche dubbio: non ci sono vincoli di chiave esterna, in nessuna tabella.
manage.py
ha il comando inspectdb
che estrae le classi python per i modelli, andando a leggersi un database pre-esistente, e anche questo conferma che, ad esempio, scuola ha al suo interno un campo per l'id di area, ma sembrano non esserci vincoli di chiave esterna a livello database.
È possibile che turbogears 1.0.8 facesse enforcing di questi vincoli a un livello diverso del livello database?
Può creare problemi usare campi di tipo models.ForeignKey
o models.ManyToManyField
con django sul database mysql fatto in questo modo?
Allego il file SQL con lo schema estratto da MySQL e il file python creato da manage.py
.
Updated by Christopher R. Gabriel over 11 years ago
- Assignee changed from Christopher R. Gabriel to Mark Caglienzi
Non saprei risponderti. L'unica e' provare a vedere se django si lamenta a riguardo importando il dump in un mysql locale e provare.
Updated by Christopher R. Gabriel over 11 years ago
Sicuramente se ci sono chiavi esterne e' bene che il db le sappia, quindi magari valutiamo di generare il db ammodo e poi di reimportarci dentro i dati con delle belle '''insert from select''', che era una delle due opzioni descritte nel ticket.
Updated by Mark Caglienzi over 11 years ago
- Assignee changed from Mark Caglienzi to Christopher R. Gabriel
Per ora ho messo un db_router nell'app schools
e ho implementato i modelli Area
e School
(quest'ultimo non completamente, mancano tutte le relazioni con i modelli mancanti, che andranno aggiunte/i passo passo).
Il db_router mi permette di disabilitare la creazione delle tabelle quando si fa sync_db
per le app che si appoggiano a MySQL (mentre tutto il resto viene buttato nel solito SQLite per lo sviluppo senza rischiare di modificare il dump del db di produzione). In questo modo si possono testare i modelli praticamente uno per uno abilitandone l'accesso alla connessione verso MySQL.
Dato che ho School
e Area
, c'è già dichiarata nel modello la ForeignKey
tra questi due modelli, e la cosa sembra piacere a Django, tant'è che le view areas()
e area(id)
funzionano.
PS: ricordarsi di fare il solito symlink a settings.py.devel
e di inserirci i dati di accesso al dump di MySQL che girerà in locale durante lo sviluppo e i test.
Updated by Christopher R. Gabriel over 11 years ago
- Assignee changed from Christopher R. Gabriel to Mark Caglienzi
Bene, bravo :) vai avanti, questo il mio unico commento :)
Updated by Christopher R. Gabriel over 11 years ago
- Status changed from Nuovo to Chiuso
- Resolution set to fixed
Abbiamo risolto rimuovendo i db_router, usando direttamente il db esistente. Chiudo.