transazioni Firebase tramite API REST

trovo transazioni (https://www.firebase.com/docs/transactions.html) per essere un modo intelligente di gestire la concorrenza, tuttavia sembra che può essere fatto solo da parte dei clienti.transazioni Firebase tramite API REST

Il modo in cui usiamo Firebase è principalmente scrivendo i dati dai nostri server e osservandoli sui client. Esiste un modo per ottenere un modello di concorrenza ottimista durante la scrittura dei dati tramite l'API REST?

Grazie!

fonte

2014-04-13 Martin Šťáva

Ciao Martin, come immaginate che il lavoro? Tenete a mente che che le operazioni si basano sulla discussione un back-e-indietro dove il cliente continua a tentare di impostare i dati, il server continua a rispondere con modifiche simultanee, e alla fine stabilirsi su un valore o rinunciare. – Kato

Ciao Kato, certo, sto cercando di implementare esattamente la stessa discussione sul lato server. Posso ottenere lo stato attuale di un oggetto all'interno di firebase tramite la richiesta GET e quindi cambiarlo tramite PUT, ma c'è un modo per sapere se quell'oggetto è stato modificato nel frattempo? –

Io non la penso così; che è parte del problema con le transazioni di prova tramite REST. Suppongo che potremmo mettere insieme una soluzione che simuli le transazioni abbastanza facilmente. Lasciami una risposta – Kato

si potrebbe utilizzare un contatore di aggiornamento per rendere ops scrittura funzionano in modo simile alle transazioni. (Ho intenzione di usare qualche pseudo-codice qui sotto, mi dispiace ma non volevo scrivere un'API REST completa per un esempio.)

Ad esempio, se ho un oggetto come questo:

{ 
    total: 100, 
    update_counter: 0 
}

E una regola di scrittura come questo:

{ 
    ".write": "newData.hasChild('update_counter')", 
    "update_counter": { 
     ".validate": "newData.val() === data.val()+1" 
    } 
}

ora potevo evitare modifiche simultanee semplicemente passando nel update_counter con ogni operazione. Per esempio:

var url = 'https://<INSTANCE>.firebaseio.com/path/to/data.json'; 
addToTotal(url, 25, function(data) { 
    console.log('new total is '+data.total); 
}); 

function addToTotal(url, amount, next) { 
    getCurrentValue(url, function(in) { 
     var data = { total: in.total+amount, update_counter: in.update_counter+1 }; 
     setCurrentValue(ref, data, next, addToTotal.bind(null, ref, amount, next)); 
    }); 
} 

function getCurrentValue(url, next) { 
    // var data = (results of GET request to the URL) 
    next(data); 
} 

function setCurrentValue(url, data, next, retryMethod) { 
    // set the data with a PUT request to the URL 
    // if the PUT fails with 403 (permission denied) then 
    // we assume there was a concurrent edit and we need 
    // to try our pseudo-transaction again 
    // we have to make some assumptions that permission_denied does not 
    // occur for any other reasons, so we might want some extra checking, fallbacks, 
    // or a max number of retries here 
    // var statusCode = (server's response code to PUT request) 
    if(statusCode === 403) { 
     retryMethod(); 
    } 
    else { 
     next(data); 
    } 
}

fonte

2014-04-14 19:02:15 Kato

Sembra molto stimolante, grazie mille! Proverò a implementarlo e farti sapere se qualche problema. –

Funziona perfettamente per l'aggiornamento degli oggetti. È possibile implementare una cosa simile per l'eliminazione? –

@ MartinŠťáva In realtà non è possibile farlo, perché non si passano dati con DELETE. Non credo che la maggior parte dei sistemi si preoccupino di questo, perché assumono che se si dice DELETE, si intende realmente DELETE e non importa cosa ci fosse prima, a patto che si stia facendo riferimento alla chiave/URL corretta. –