Come aggiornare il modulo dell'interfaccia utente tramite l'aggiornamento del database

Question

Come aggiornare il modulo dell'interfaccia utente tramite l'aggiornamento del database

#1 da (1 voti)

0

Ho un'applicazione client server. Supponiamo che io lavori come dirigente di supporto, risolvendo i ticket dei clienti. Noi (il nostro team di supporto) abbiamo due biglietti su cui lavorare.

Ticket 1: il cliente "Liver" ha alzato un ticket per aggiornare il suo numero di telefono.
Ticket 2: lo stesso "Liver" del cliente ha alzato un secondo ticket per aggiornare il suo ID e-mail.

Sto lavorando al ticket 1:

Aperta l'applicazione, fai clic su modifica Buttton Info cliente, inserisci il nuovo numero di telefono. Non ho salvato il modulo (Modifica modulo). In mezzo, sono partito per CUPPA.

Il mio collega sta guardando il ticket 2: ha modificato le informazioni del cliente e aggiornato con il nuovo ID e-mail: è rimasto nel database.

Quando, torno indietro e salvo il mio biglietto con l'aggiornamento del numero di telefono, esso sovrascriverà le sue modifiche, ad esempio, la sua modifica dell'ID e-mail verrà persa o non aggiornata per quel "Fegato" del Cliente.

C'è un modo in cui, quando ritorni al mio lavoro / pagina dopo l'interruzione di CUPPA, posso vedere l'ID e-mail con il valore aggiornato?

Come prevenirlo? Qual è l'approccio? Possibili idee di design? Come garantire che non ci siano perdite di dati?

design java web-applications mvc

posta srk 28.11.2013 - 14:07

fonte

1 risposta

Leggi altre domande sui tag design java web-applications mvc

Inverso di refactoring dell'interfaccia Extract scipy.stats.percentileofscore () sbagliato?

score 1 · Answer 1

I due modi più semplici per evitare che ciò accada sono

Utilizzare un modulo di blocco (a livello utente) nel database.

Quando si caricano le informazioni del client "Fegato" nel modulo, viene inserito un marker nel database che il client "Liver" è attualmente in fase di modifica (e probabilmente da chi). Quando il tuo collega tenta di caricare anche il client "Liver", verrebbe informato che tu (o qualcuno) stai già modificando il client "Liver" e che non può accedere ai dati per tale motivo. Quando alla fine invii le tue modifiche, il "flag di modifica" verrebbe rimosso dal database.
Utilizza il controllo delle versioni dei dati.

In questo schema, ogni set di dati nel database riceve un numero di revisione che viene incrementato con ogni aggiornamento. Nello scenario descritto, sia tu che il tuo collega inizierete con i dati della revisione 42 del client "Liver". Poiché il tuo collega è il primo a risparmiare, le sue modifiche vengono accettate immediatamente e la revisione diventa 43. Quando si tenta di salvare, il livello del database noterebbe che le modifiche sono basate sulla revisione 42, ma la revisione corrente è 43, quindi le modifiche vengono rifiutate. Quindi l'applicazione può recuperare la versione 43, provare a unire le modifiche in quella versione e informarti che qualcun altro ha già apportato delle modifiche. Puoi quindi ricontrollare se la tua modifica è ancora valida e provare a salvare di nuovo.

La principale differenza con ciò che hai chiesto è che l'aggiornamento del modulo da parte tua è in ritardo fino a quando non provi a salvare.