IdentityMap: come gestisco le query?

Ciao alkampfer,

innanzitutto grazie per la risposta.

alkampfer ha scritto:
> Ciao, vediamo di dare qualche spiegazione.

> Per reidratare si intende l'operazione di ricostruire l'oggetto in
> memoria dai dati tornati dal database.
[cut]

Dunque, vediamo se ho capito.
Io sono l'istanza a1 della classe A e chiedo al mio FooService di darmi
listanza di Foo con id "12". Se l'istanza a2 della classe A richiede al
FooService l'istanza di Foo con id "12" il FooService:
- chiede alla IdentityMap se l'entità di tipo Foo è già stata caricata,
- se si, la manda ad a2,
- altrimenti richiama un GetByID("12") dal
repository/provider/datamapper/datacontext/quellochevuoi delle entity
Foo che la fetcha dal database,
- la manda ad a2.
Corretto o sbagliato? :-)

> Tipicamente l'ORM esegue la
> query, ottiene un datareader e per ogni riga ricostruisce gli oggetti
> prendendo i dati dal db. E' in questo momento che un orm controlla la
> chiave primaria nel datareader, controlla nella IM se è presente un
> oggetto con quella chiave, se si prende quello e non reidtrata nulla.

Uhm... considera che non uso un ORM per due motivi:
- non è "contemplato" nei requisiti,
- il modello "relazionale" dei dati del mio db è molto diverso dal
modello delle business entities.

> Il flush consiste in questo
[cut]

Ok, questo credo di averlo capito.

Grazie,
Giulio
--
http://www.giuliopetrucci.it
http://www.myspace.com/fujikomonamourtheband

La situazione è più o meno questa

CAso1: io chiedo a FooService una entità specificando la sua chiave primaria, tipo "dammi foo con id 23", lui prima guarda su IM se trova l'oggetto restituisce sempre quello, altrimenti lo prende dal db. Questo evita alias, ovvero evita che se il chiamante chiede due volte un foo con id 23 riceva due oggetti distinti.

Caso2: Io chiedo a FooService tutti i Foo con una certa caratteristica, tipo età > 20. Prima di tutto faccio un flush, ovvero scrivo nel db tutte le eventuali modifiche degli oggetti in memoria, secondo faccio la query al db where età > 20, terzo per ogni record tornato controllo la chiave se è nell'IM altrimenti ricostruisco l'oggetto.

Per la parte di flush devi tenere da qualche parte una copia dell'entità con i valori originali con cui confrontare poi i cambiamenti, oppure puoi richiedere che le entità iplementino INotifyPropertyChanged, etc.

alk.

Ciao alkampfer

alkampfer ha scritto:
> CAso1: io chiedo a FooService una entità specificando la sua chiave
> primaria, tipo "dammi foo con id 23", lui prima guarda su IM se trova
> l'oggetto restituisce sempre quello, altrimenti lo prende dal db. Questo
> evita alias, ovvero evita che se il chiamante chiede due volte un foo
> con id 23 riceva due oggetti distinti.

Ok, fin qui ci siamo. :-)

> Caso2: Io chiedo a FooService tutti i Foo con una certa caratteristica,
> tipo età > 20. Prima di tutto faccio un flush, ovvero scrivo nel db
> tutte le eventuali modifiche degli oggetti in memoria, secondo faccio la
> query al db where età > 20, terzo per ogni record tornato controllo la
> chiave se è nell'IM altrimenti ricostruisco l'oggetto.

Ok, anche questo è chiaro... o meglio, credo sia chiaro. :-)
Se non ho capito male il flush serve per evitare che sessioni
concorrenti accedano a valori inconsistenti, giusto?

> Per la parte di flush devi tenere da qualche parte una copia dell'entità
> con i valori originali con cui confrontare poi i cambiamenti, oppure
> puoi richiedere che le entità iplementino INotifyPropertyChanged, etc.

Questo invece mi è oscuro. Ai fini del flush (e *solo* ai fini del
flush) sapere se una entità è cambiata mi serve solo per scegliere se
richiamare l'update o no, giusto?

Ciao e garzie,
Giulio
--
http://www.giuliopetrucci.it
http://www.myspace.com/fujikomonamourtheband

petrux:

Ciao alkampfer

Ok, anche questo è chiaro... o meglio, credo sia chiaro. :-)
Se non ho capito male il flush serve per evitare che sessioni
concorrenti accedano a valori inconsistenti, giusto?

Non propriamente, quella che tu dici è la concorrenza. Il flush serve perchè tu fai la query al database, ma nel frattempo i dati in memoria potrebbero essere cambiati. Il flush serve quindi a propagare le modifiche in memoria al db, cosi quando esegui la query nel db sei sicuro che i dati siano gli stessi di quelli in memoria.

petrux:

> Per la parte di flush devi tenere da qualche parte una copia dell'entità
> con i valori originali con cui confrontare poi i cambiamenti, oppure
> puoi richiedere che le entità iplementino INotifyPropertyChanged, etc.

Questo invece mi è oscuro. Ai fini del flush (e *solo* ai fini del
flush) sapere se una entità è cambiata mi serve solo per scegliere se
richiamare l'update o no, giusto?

Si infatti, il flush confronta i valori delle proprietà dell'oggetto al momento del caricamento, con quelli attuali. In questo modo capisce se tu hai cambiato qualche proprietà e genera le update corrispondenti .

 

alk.

Ciao alkampfer,

alkampfer ha scritto:
> Non propriamente, quella che tu dici è la concorrenza. Il flush serve
> perchè tu fai la query al database, ma nel frattempo i dati in memoria
> potrebbero essere cambiati. Il flush serve quindi a propagare le
> modifiche in memoria al db, cosi quando esegui la query nel db sei
> sicuro che i dati siano gli stessi di quelli in memoria.

Ok, tutto chiarissio.

Grazie davvero e buona giornata,
Giulio
--
http://www.giuliopetrucci.it
http://www.myspace.com/fujikomonamourtheband

Felice di averti aiutato. ciao ciao e Buona giornata anche a te. :)

alk.