Newsgroup: it.comp.os.linux.software
Titolo: Re: XPN Testing (refresh)

 ammettere che e' efficace.
Beh ... leafnode lo fa. Il formato Maildir č fatto cosě.
Il mio dubbio ripeto č che ho notato sulla mia pelle come le prestazioni siano
in questo caso molto influenzate dal filesystem.
-- 
There's a fine line between genius and insanity. I have erased this
line.
 _  _                  _
| \| |___ _ __  ___ __(_)___
| .` / -_) '  \/ -_|_-< (_-<
|_|\_\___|_|_|_\___/__/_/__/ 
http://xpn.altervista.org

 lavoravano con file ASCII, hanno fatto di necessita' virtu'?
Se non ho capito male, stai dicendo di mettere gli header su di una
tabella ed il body su di un file (ovviamente vi e` una associazione 1:1
tra l'header registrato ed il nome del file). La cosa non ha senso, in
quanto ti ritroveresti ad avere problemi con i limiti del file system
(teoricamente), senza contare la complessita` di dover gestire due
strutture differenti. Inoltre devi considerare anche un'altra cosa: su
Pan ci lavora piu` di una persona, percio` non mi stupirei che la parte
di salvataggio degli articoli sia stata estremamente ottimizzata.
Infine, se reputi che avere due tabelle sullo stesso database possa
essere un problema, si potrebbe provare a mettere la tabella dei body su
di un altro database e collegarla al db degli header (operazione
permessa da SQLite). Ma ribadisco: non ha senso
Enrico

 join.
Si, con SQLite e` fattibile
Enrico

 Lo sento che macina per un po'.
si è vero ...  non saprei come migliorare la cosa ... l'unica cosa che
ho potuto fare è di non fare un commit ogni volta ... ma probabilmente un
insert scatena il commit di quello precedente.
-- 
Honesty pays, but it doesn't seem to pay enough to suit some people.


 insert scatena il commit di quello precedente.
Dipende da come intendi la cosa. Se intendi che fai un insert e poi un
commit, allora e` un problema di come hai scritto il codice[1]. Se
invece intendi che un insert fa eseguire un commit, allora e`
impossibile. L'unico motivo per cui puo` succedere una cosa del genere
e` perche` la connessione che si e` aperta e` in modalita` autocommit.
Comunque, anche se la connessione e` in autocommit, le operazioni sono
sempre e comunque talmente veloci che non vanno ad influire pesantemente
sulle prestazioni del sistema (sopratutto tenendo in considerazione lo
scopo dell'applicazione). Infine, a me questo mi sembra un problema
secondario
Enrico
[1] c'e` anche da analizzare quanto un comportamento del genere possa
essere considerato un problema. Eseguire un commit subito dopo
un'operazione DML, garantisce che le operazioni di manipolazione dei
dati siano correttamente scritte sul database. Di conseguenza, questo mi
permette di essere sicuro che tutto e` andato a buon fine

 secondario
Beh non del tutto, in effetti l'inserimento è lento, più di quanto mi
aspettassi, e probabilmente è più lento del metodo vecchio, ovvero
l'inserimento nello shelve.
-- 
Zoo: An excellent place to study the habits of human beings.


 sempre su un unico file piccolissimo.
Che sia fattibile non l'ho mai messo in dubbio, e` la logica che vi sta
dietro che secondo me non ha senso. Indipendentemente dalla dimensione e
dal numero di file che lo compongono, l'accesso ai dati di un database
e` sempre veloce e uniforme[1]. Inoltre, su di un database, io devo
tenere in mente solo un tipo di dato: il record. L'uso di tanti file e,
conseguentemente, di un file indice, mi manda incontro a problemi
indipendenti dalla mia implementazione (e.g. l'uso su di un file system
che non supporta piu` di n file per directory), senza contare che mi
costringe a tenere in mente non uno, ma due tipologie di dati: il
record e l'indice
Enrico
[1] grazie al cavolo, direi, visto che la velocita` e l'uniformita` sono
due obiettivi di qualsiasi RDBMS

 l'inserimento nello shelve.
Tieni presente che ci sono n motivi per cui un inserimento risulta
lento. Due di questi sono proprio la presenza di indici e di trigger.
Per spiegarmi meglio, l'inserimento di una entry nella tabella articles
comporta il check del trigger e, successivamente, l'inserimento delle
informazioni necessarie agli indici per essere utilizzabili in fase di
selezione dei dati. In altre parole, l'uso di strutture accessorie alla
tabella (come trigger e indici) e` utile per implementare funzionalita`
e per migliorare le performance di lettura, ma le operazioni di
scrittura e modifica ne risentono
Enrico
P.S. se non si fosse capito, devi scendere a compromessi

 P.S. se non si fosse capito, devi scendere a compromessi
Lo so, magari fosse tutto velocissimo.
Per quanto riguarda i trigger ... non so bene come vengano gestiti ,
io ne ho inserito soltanto uno che scatta alla cancellazione di un
record, a sensazione direi che non dovrebbe influenzare l'inserimento.
Per quanto riguarda gli indici ho cercato di limitarli ai campi su cui
cerco ... in effetti potrei anche fare qualche prova per vedere se si
può limare ancora qualcosa.