Project

General

Profile

Segnalazione #4

Segnalazione #1: Migrazione octomon a django

Mantenere storico dati

Added by Christopher R. Gabriel over 10 years ago. Updated over 10 years ago.

Status:
Chiuso
Priority:
Normale
Start date:
07/16/2013
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed

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

octomonschema.sql (16.9 KB) octomonschema.sql Schema del DB attuale Mark Caglienzi, 07/17/2013 02:30 PM
inspectdb-models.py (9.35 KB) inspectdb-models.py Modelli creati da manage.py Mark Caglienzi, 07/17/2013 02:30 PM

History

#1

Updated by Christopher R. Gabriel over 10 years ago

  • Parent task set to #1
#2

Updated by Mark Caglienzi over 10 years ago

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.

#3

Updated by Christopher R. Gabriel over 10 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.

#4

Updated by Christopher R. Gabriel over 10 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.

#5

Updated by Mark Caglienzi over 10 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.

#6

Updated by Christopher R. Gabriel over 10 years ago

  • Assignee changed from Christopher R. Gabriel to Mark Caglienzi

Bene, bravo :) vai avanti, questo il mio unico commento :)

#7

Updated by Christopher R. Gabriel over 10 years ago

  • Status changed from Nuovo to Chiuso
  • Resolution set to fixed

Abbiamo risolto rimuovendo i db_router, usando direttamente il db esistente. Chiudo.

Also available in: Atom PDF