Lo so che tanto siete tutti in vacanza, ma io ci provo. Ho bisogno di
un’idea per attaccare un problema…
Il problema è il seguente: mettete di avere un wiki in cui le pagine
rappreseentano istruzioni eseguite dal wiki stesso.
E’ pensabile quindi poter scrivere web apps direttamente entro il wiki,
versionando le pagine, creando dipendenze tra pagine/versioni, etc.
Il grosso problema sono i dati.
A quale app appartengono? chi li crea? chi li distrugge? come gestirli?
In
generale l’intero concetto di migration diventa molto pesante in quel
contesto.
Supponiamo che il wiki non debba servire uno zillione di utenti… ma sia
fatto per fare prototipi rapidi… in questo caso potrei avere un
in-memory
db che posso dumpare come yaml ogni X secondi/minuti, oppure il DB
potrebbe
essere un’altra pagina wiki contenente i file yaml o del testo in
formato
tabulare… oppure potrei avere un paio di tabelle fisse nel sistema che
tengono tutti i dati spezzettando le colonne di quelle che sarebbero
tabelle rails come rows all’interno di queste meta-tabelle dinamiche.
avete altre idee?
sia sulla gestione dei dati che sull’applicativo?
Lo so che tanto siete tutti in vacanza, ma io ci
provo. Ho bisogno di
un’idea per attaccare un problema…
non ancora in vacanza… ma se dio vuole entro la fine
della settimana
A quale app appartengono? chi li crea? chi li
distrugge? come gestirli? In
generale l’intero concetto di migration diventa
molto pesante in quel
contesto.
esiste un concetto di “applicazione” all’interno del
wiki?
Intendo, se io faccio “new app: foo” e poi aggiungo il
codice che la compone è relativamente semplice
assegnargli i dati, se invece un’ìapplicazione è un
concetto impreciso collegato alle pagine è pèiù
difficile. Ma anche in quel caso si potrebbe associare
il pacco di dati all’applicazione intendendo come tale
la pagina che viene eseguita.
In entrmabi i casi io vedrei bene un DB OO/gerarchico
in cui la root dei dati è il nome dell’applicazione
tengono tutti i dati spezzettando le colonne di
quelle che sarebbero
tabelle rails come rows all’interno di queste
meta-tabelle dinamiche.
non pensare in termini di tabelle, madeleine direi che
fa al caso tuo, se funziona ancora.
L’evoluzione dello schema è automatica, ed è semplice
mostrare i dati come una pagina virtuale del wiki.
Come dicevo prima, la separazione tra i vari dati è
comunque semplice pensando che ogni pagina fa da
radice per un albero di oggetti che sono quelli
dell’applicazione.
esiste un concetto di “applicazione” all’interno del
wiki?
Intendo, se io faccio “new app: foo” e poi aggiungo il
codice che la compone è relativamente semplice
assegnargli i dati, se invece un’ìapplicazione è un
concetto impreciso collegato alle pagine è pèiù
difficile. Ma anche in quel caso si potrebbe associare
non lo so ancora, tu che dici?
è possibile pensare a una non-applicazione ma solo a degli entry point
diversi su un’ecologia di logica e dati?
il pacco di dati all’applicazione intendendo come tale
la pagina che viene eseguita.
In entrmabi i casi io vedrei bene un DB OO/gerarchico
in cui la root dei dati è il nome dell’applicazione
questo semplificherebbe un pò le cose… ma quanto sarebbe fico lasciare app
e dati disaccoppiati?
si lo so mi sto complicando la vita. iniziamo come dici tu
non pensare in termini di tabelle, madeleine direi che
fa al caso tuo, se funziona ancora.
bello, un prevayler engine. lo hai provato?
L’evoluzione dello schema è automatica, ed è semplice
non lo so ancora, tu che dici?
è possibile pensare a una non-applicazione ma solo a
degli entry point
diversi su un’ecologia di logica e dati?
a parte il termine ecologia… perché no?
Magari con una micro-api del tipo
data = data(:name)
dove :name è una pagina del wiki, mantenuta come yaml
o dentro il tuo db. L’applicazione diviene
praticamente solo una vista divers sui dati. Ma è
ragionevole condividere i dati in questo modo?
A che punti inserisci le regole di dominio per
mantenerli consistenti se ognuno accede direttamente?
sarebbe fico lasciare app
e dati disaccoppiati?
si lo so mi sto complicando la vita. iniziamo come
dici tu
complicando la vita no, solo che mi prude la schiena a
pensare che una pagina che fa casini manda a donnacce
tutte le applicazioni. D’altronde se il metodo di
accesso ai dati usa il versioning potrebbe
funzionare…
non pensare in termini di tabelle, madeleine direi
che
fa al caso tuo, se funziona ancora.
bello, un prevayler engine. lo hai provato?
un sacco di tempo fa e funzionava discretamente.
Era anche la cosa con cui funzionava instiki quindi
dovrebbe avere una certa affidabilità, ma ripeto non
so se si aggiornato per andare correttamente con ruby
1.8.6
Il giorno mar, 31/07/2007 alle 12.47 +0200, chiaro scuro ha scritto:
concetto impreciso collegato alle pagine è pèiù
in cui la root dei dati è il nome dell’applicazione
Sono d’accordo con Gabriele qui.
questo semplificherebbe un pò le cose… ma quanto sarebbe fico lasciare app
e dati disaccoppiati?
Non sarebbe per niente fico
Personalmente ritengo il disaccoppiamento tra applicazione e dati una di
quelle idee che suonano bene sulla carta, ma in pratica non funzionano.
si lo so mi sto complicando la vita. iniziamo come dici tu
non pensare in termini di tabelle, madeleine direi che
fa al caso tuo, se funziona ancora.
bello, un prevayler engine. lo hai provato?
Io non ho provato Madeleine, ma ho avuto esperienze con db a oggetti (in
Smalltalk) e devo dire che rendono molte cose molto più semplici. Quindi
ti direi di andare di Madeleine.
Certo che se Ruby avesse un immagine come Smalltalk, non avresti neanche
il problema: ti limiteresti a salvare l’immagine
Il 31/07/07, chiaro scuro [email protected] ha scritto:
Premetto che sono in vacanza e intendo restarci ma vorrei suggerirti di
creare al volo dei piccoli db sqlite, uno per webapp. Facili da versionare
(una migration è semplicemente un’altra entry del wiki), gestire (sono
file)
e per rintracciarli basta fare un match webapp-file. Oltretutto esistono
non è male affatto come idea. l’idea di vedere il db come file me lo fa
sembrare meno minaccioso in questo contesto
mi ero fissato con il fatto che ci volesse un meccanismo diverso e non
ci ho
pensato. adesso provo a vedere se è fattibile…
E’ un’idea semplicistica? Ci avevi pensato? Se sì, perché l’hai scartata?
avete altre idee?
sia sulla gestione dei dati che sull’applicativo?
Premetto che sono in vacanza e intendo restarci ma vorrei suggerirti
di
creare al volo dei piccoli db sqlite, uno per webapp. Facili da
versionare
(una migration è semplicemente un’altra entry del wiki), gestire (sono
file)
e per rintracciarli basta fare un match webapp-file. Oltretutto esistono
plugin per rails che ti permettono di connetterti a db diversi, non so
il
nome ma mi ricordo che sono stati trattati qui in questa ml.
E’ un’idea semplicistica? Ci avevi pensato? Se sì, perché l’hai scartata?
non è male affatto come idea. l’idea di vedere il db come file me lo fa
sembrare meno minaccioso in questo contesto
mi ero fissato con il fatto che ci volesse un meccanismo diverso e non ci
ho
pensato. adesso provo a vedere se è fattibile…
ma vorrei suggerirti di