Persistenza dei dati in Smalltalk/Seaside

Question

Ho trascorso un po 'di tempo a familiarizzare con Smalltalk e Seaside. Vengo dal mondo Java EE e come puoi immaginare è stato impegnativo pensare ai concetti di Smalltalk. :)

Al momento sto cercando di capire come la persistenza dei dati sia in genere implementata nel mondo Smalltalk. L'assunto per me come programmatore Java è usare RDMS (cioè MySQL) e ORM (cioè Hibernate). Capisco che non è il caso di Smalltalk (utilizzando almeno Hibernate). Non sto necessariamente cercando il metodo più vicino al modo in cui è fatto in Java EE.

È più comune salvare i dati nell'immagine, in un archivio oggetti o RDMS? È tipico anche per le app Smalltalk utilizzare RDMS?

Capisco che non esiste un approccio valido per tutti e che la strategia di persistenza corretta dipenderà dalle esigenze dell'applicazione (quanti dati, concorrenza, ecc.). Qual è un buon approccio che può iniziare in modo semplice ma anche in scala?

Ho visto uno video di Avi Bryant discutendo la strategia che ha usato per la persistenza e il ridimensionamento di DabbleDB. Da quello che ho capito, i dati del cliente sono stati salvati direttamente nell'immagine (un'immagine per cliente). Ciò ha funzionato nel suo caso d'uso poiché i clienti non dovevano condividere i dati. È un approccio comune?

Spero di non aver creato questo TLDR. Mille grazie per l'intuizione che i ragazzi di Smalltalk hanno fornito nelle mie precedenti domande. È apprezzato

Answer 1

Justin,

non preoccupatevi, Smalltalk non è così diverse forma altre lingue in questo settore, si aggiunge solo l'opzione di persistenza basata immagine.

Ci sono O/R mapper come Hibernate per Smalltalk, il GLORP e la sua porta Pharo DBXtalk sono sicuramente i più popolari in questi giorni. Questi dovrebbero sentirsi molto bene per te se conosci Hibernate.

Quindi ci sono soluzioni OODB come GemStone o Magma DB o VOSS e molte altre che consentono di lasciare indietro tutti i problemi di mappatura O/R. Molti di questi sono piuttosto limitati alla memorizzazione di oggetti Smalltalk, GemStone rappresenta un'eccezione nel fornire bridge a Ruby e ad altre lingue.

Esistono anche strumenti per memorizzare oggetti Smalltalk in database moderni NoSQL come CouchDB, Cassandra, GOODS o altri. Il trucco qui è solo la conversione dei valori degli oggetti Smalltalk in stream JSON e una piccola richiesta HTTP.

Infine, è possibile salvare l'immagine Smalltalk completa. Direi che puoi farlo in un ambiente di produzione, ma non è il modo standard o preferito di dong per molte persone. Lo fai molto in fase di sviluppo, perché puoi semplicemente salvare un'immagine e riprendere il tuo lavoro la prossima volta esattamente con tutti gli oggetti sul posto che avevi quando li hai salvati.

Quindi la linea di base è: tutte le opzioni di archiviazione che conosci sono disponibili anche in Smalltalk, più un extra.

Joachim

Answer 2

credo che fondamentalmente dipende da quanto è grande il vostro DB sta per essere e che tipo di carico saranno oggetto di manipolazione.

Nel mio caso, tutte le app che ho mai scritto usano la persistenza dell'immagine con la serializzazione del disco. In sostanza, serializzi semplicemente i tuoi oggetti usando Carburante su richiesta.Nel mio caso, lo faccio ogni volta che viene trattata una parte importante dei dati, oltre a un processo regolare che li serializza ogni 24 ore. L'immagine viene inoltre salvata automaticamente ogni 24 ore.

La più grande applicazione che ho scritto utilizzando questo approccio è la gestione di tutti i processi aziendali di una piccola azienda di 10 lavoratori più una cinquantina di liberi professionisti che l'hanno utilizzata ogni giorno per un anno e mezzo. Il carico di lavoro è piuttosto "grosso", tenendo conto che l'applicazione si occupa di file di grandi dimensioni in ogni momento, ma l'app è rimasta stabile e veloce. Passare a un nuovo server e aggiornare l'immagine Pharo è stato facile come riprendere il progetto da Monticello e materializzare l'ultimo "database" serializzato.

A mio parere, l'ORM è un dolore non necessario, siamo nel mondo degli oggetti, e dover appiattire i nostri oggetti si sente semplicemente sbagliato, specialmente quando abbiamo delle belle soluzioni orientate agli oggetti.

Quindi, se l'app gestisce quantità di dati piuttosto piccole, suggerirei il mio approccio semplice o SandstoneDB. Se la tua app si occupa di enormi quantità di transazioni e dati, andrei Gemstone.

Solo i miei due centesimi.

Answer 3

Ramon Leon descrive la situazione, le strategie di base e i loro compromessi splendidamente in his blog post.

Vorrei iniziare con il framework Simple Image Based Persistence, che I ported e utilizzare in Pharo 1.3. Mariano Martinez Peck l'ha adattato di recente a utilizzare Carburante (stesso link). È molto semplice, fa il lavoro e mi dà molta più sicurezza per giocare nella mia immagine, sapendo che anche se lo danneggiavo in modo permanente, tutti i miei dati sono al sicuro. Copio semplicemente le cartelle di dati nella nuova cartella di immagini, carico i miei pacchetti e tutti i miei oggetti sono vivi nella nuova immagine.