Il giorno 07 marzo 2011 13:57, Clauz <[email protected]> ha scritto: > On 03/07/2011 11:42 AM, Claudio wrote: > > Il 07 marzo 2011 11:38, Clauz <[email protected]> ha scritto: > >> Pensandoci: se usassimo un database testuale potremmo anche usare git (o > >> mercurial) come backend... > > > > esplicita meglio la tua idea, come faresti? dettagli architetturali plz > > Innanzitutto si potrebbero (o anche no) implementare gli utenti, con > differenti permessi: tutti possono vedere la history, magari con diff > tra revisioni, ma solo gli admin possono fare i revert. > > Ho in mente una cosa tipo questa: > http://battlemesh.org/BattleMeshV4?action=info > > Diciamo che è possibilissimo. Solo che non capisco a cosa serva ora se siamo solo pochi developer, certo approntarlo ora evita il casino dopo, comunque non sono contrario, solo da convincere perché non riesco a capire fino in fondo l'utilità.
> > Con git: > > Sotto vengono fatte chiamate a git (diff, log, etc) parsate e presentate > agli utenti. > > Drawback: per fare questa cosa serve un database dei nodi su file > testuale, rinunciando a mysql o postgres. > > > Senza git: > > C'e' un modo nativo di 'versionare' la tabella di un database? So che > postgresql di fatto sotto tiene traccia delle versioni [0] (e, scopro > ora da wikipedia, anche mysql!) ma non credo che siano accessibili > all'utente del database... > > Se no si fa una nuova tabella con la lista di operazioni effettuate > sulla mappa: > > operations (timestamp, node_id, user, op_type, op_params) > > - timestamp e user sono momento e utente (o indirizzo IP) che effettua > l'operazione > - node_id e' l'id del nodo coinvolto nell'operazione > - op_type puo' essere: insert, delete, edit_type, edit_location, edit_ip > - op_params e' un campo il cui significato varia a seconda del tipo di > operazione (hai presente assembler? :)) per cui, nel caso di: > - 'insert' dentro op_params ci va null (tutti i dati del nodo stanno > nella tabella dei nodi) > - 'delete' dentro op_params ci va null, ma bisogna fare in modo che > il nodo non venga effettivamente cancellato dalla tabella dei nodi ma > solo marcato come cancellato (impostando il tipo di nodo a -1 per esempio) > - 'edit_type' dentro op_params ci vanno il tipo di nodo vecchio ed il > tipo di nodo nuovo, separati da punto e virgola > - 'edit_location' dentro op_params ci va: old_lat,old_lng,old_alt; > new_lat,new_lng,new_alt (si capisce?) > - 'edit_ip' dentro op_params ci mettiamo: ip_vecchio; ip_nuovo > > Queste operazioni "da history" sono realizzabilissime e senza sbattersi tanto. So già come fare. Giovedì ve le illustro, così mi dici Caluz se ho capito bene la tua idea. > P.S. in realta' i database relazionali, soprattutto in ambito web, sanno > un po' di vecchio se confrontati con roba come couchdb [1], ma la curva > di apprendimento e' piuttosto ripida... > > Passare ad un No-SQL DB quando vuoi, ho pronto tutto quello che serve ! In più al codemotion ho visto anche qualcosa di nuovo e quasi pronto, solo che non so se realizzabile in PHP. Giorgio -- Il saggio coltiva Linux, perché sà che Window$ si pianta da solo ! “To iterate is human, to recurse divine.” (L. Peter Deutsch)
_______________________________________________ Wireless mailing list [email protected] http://ml.ninux.org/mailman/listinfo/wireless
