ServiceStack OrmLite - Gestione colonne predefinite e calcolate

Question

In che modo ServiceStack OrmLite gestisce le colonne predefinite e calcolate?

In particolare sto ottenendo l'errore

The column "PointsAvailable" cannot be modified because it is either a computed column or is the result of a UNION operator. 

Questa colonna è configurato come una colonna calcolata in un database SQL Server 2008.

OrmLite sembra fare qualcosa con le colonne calcolate poiché è possibile aggiungere l'attributo '[ServiceStack.DataAnnotations.Compute]' a una proprietà in un modello.

Passando al codice, viene richiamata la funzione "ToInsertRowStatement" in "OrmLiteDialetBase.cs". Mentre quella funzione controlla se la proprietà AutoIncrement è impostata, non controlla se la proprietà IsComputed è impostata.

Non so se questo è un bug o se sto solo usando male.

Answer 1

Mi preoccupo di creare una vista con le colonne pertinenti (escluse le colonne calcolate) dalla tabella e lavorare invece dalla vista. In questo modo si evitano i riferimenti a colonne calcolate indesiderate. Le viste semplici possono essere trattate allo stesso modo delle normali tabelle per quanto riguarda l'inserimento, l'eliminazione, l'aggiornamento e la maggior parte degli altri aspetti.

Answer 2

Per le mie colonne calcolate che sono calcolati solo nel livello di servizio, SQL sa nulla di loro, così ho usato una combinazione dei seguenti attributi sul modello servicestack:

[Compute, ServiceStack.DataAnnotations.Ignore] 
public List<MyModel> MyList {get;set;} 

La differenza sembra essere la Attributo "Ignora" che ha insistito per avere il suo spazio dei nomi allegato ??. Con questi in atto, vengono eseguite le query di base, altrimenti SQL si lamenta che le colonne non esistono - giustamente!

È possibile, come suggerito da t-clausen.dk, utilizzare un filtro SQL passando specificamente una stringa SQL CommandText con tutti i nomi di colonna desiderati, ma penso che si apra un problema di manutenzione.

Come per una correzione di bug che esamina il database, sembra che l'SQL sia generato su base per-provider da un metodo "toSqlString()" o simile. Quindi ci sono probabilmente alcuni punti a cui prestare attenzione ...

EDIT: È semplicemente l'attributo Ignore che fa il lavoro. Dalla sorgente:

/// IgnoreAttribute 
/// Use to indicate that a property is not a field in the table 
/// properties with this attribute are ignored when building sql sentences 

C'è anche la possibilità di utilizzare un ALIAS che non ho esplorato.