Domanda

Usando SubSonic 3 ActiveRecord, ho generato codice da un database esistente che aveva chiavi esterne. Per garantire che lo schema del database sia sempre corretto quando si cambia database, ho inserito il codice di migrazione all'inizio dell'app, usando IDataProvider.MigrateToDatabase<MyClass>() per ogni classe generata da ActiveRecord.tt. Si scopre che il codice di migrazione non rigenera le chiavi esterne.

Come devo gestire gli FK:

  • Dimentica completamente gli FK e gestisci le eliminazioni a cascata nel codice. Pro: The Rails, la logica aziendale è mantenuta nel codice. Contro: necessità di gestire le transazioni, il codice diventa molto più brutto; il roundtrip dello schema tra database e ActiveRecord diventa impossibile se il database viene commutato / cancellato (è necessario mantenere sempre lo schema originale per rigenerare / modificare il codice AR, altrimenti si perderanno le proprietà da uno a molti generate?); inoltre, i miei colleghi potrebbero pensare che io sia pazzo.
  • Aggiungi un passaggio alle migrazioni per creare manualmente FK. Pro: lo schema sarà sempre aggiornato; Il codice AR sarà sempre possibile rigenerare. Contro: dipendenza dal database (problema minore?)
  • In qualche modo trova un modo per definire le relazioni FK nel codice in modo che lo schema possa essere migrato correttamente.

Sto sbagliando? Gradirei qualsiasi consiglio.

È stato utile?

Soluzione

Sto lavorando su cose FK in questo momento per le lezioni e ci crediate o no - è piuttosto difficile. Se la tua classe genitore contiene un elenco di una classe figlio - sono molte / molte? Forse - se la tua classe figlio contiene un riferimento indietro. Questo è un presupposto debole (bidirezionale non è un buon design).

In ogni caso.

AR è pensato soprattutto per i primi DB, quindi crea il tuo database come preferisci, quindi esegui modelli AR. I tuoi FK saranno onorati e così via.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top