Lo schema del database di un'applicazione è raramente risolto, a causa del nuovo sviluppo che lo schema deve modificare. Questo vale anche per una soluzione senza schema come MongoDB. Esiste documentazione su come gestire le modifiche dello schema, cioè se un la proprietà è stata rimossa / rinominata, ecc. Il mio problema è come interrogare i dati dopo una tale modifica dello schema.
Questo è meglio illustrato con un esempio troppo semplificato. Considera la classe Persona
public class Person //version 1.0
{
public Guid Id {get;set;}
public string FirstName {get;set;}
public string LastName {get;set;}
}
Al momento della prima versione, c'è l'ipotesi mal concepita secondo cui due persone non possono avere lo stesso nome. Quindi, per recuperare un'entità di una persona dal database, troverei il record per ID o chiamerei il metodo "Trova"
public class DbContext
{
public IEnumerable<T> Find(Expression<Func<T, bool>> expression)
{
return _mongoDocumentCollection.AsQueryable().Where(expression).ToList();
}
private readonly IMongoCollection<T> _mongoDocumentCollection;
//implementation omitted
}
Un esempio di utilizzo di Trova:
new DbContext().Find(p => p.FirstName + p.LastName == "JohnDoe");
Qui interrogo così la raccolta usando un'espressione. Come accennato in precedenza, questo codice non funzionerà per molto tempo poiché più persone possono avere lo stesso nome. Quindi, aggiungiamo un campo con un nome utente.
public class Person //version 2.0
{
public Guid Id {get;set;}
public string FirstName {get;set;}
public string LastName {get;set;}
public string UserName {get;set;}
}
Quando recuperi un documento scritto nella v1.0 da id , seguiamo la strategia delineato qui , che aggiungerà programmaticamente il campo UserName concatenando il nome e il cognome. Tuttavia, facendo
new DbContext().Find(p => p.UserName == "JohnDoe");
non troverà mai il documento scritto in v1.0 poiché non contiene la proprietà UserName .
L'azienda vuole che i documenti vengano sostituiti solo se vengono effettivamente modificati, quindi scrivere uno script di migrazione non è una soluzione. Ciò implica anche che alla fine posso avere N versioni differenti della stessa classe nella raccolta di documenti, ad esempio v1.0, v2.0, .... vN. Quali schemi / strategie di progettazione sono per interrogare i dati dopo una modifica dello schema?