Poiché si fa una fatica bestiale a trovare una soluzione all'argomento la metto qui...
Se GAMLN genera un errore "unknown authorization header" ci sono buone possibilità l'errore sia dovuto ad acrobat reader...
Copiando ad incollando gli scope da autorizzare il carattere "-" in apps-apis.google.com viene interpretato come un carattere di a capo, scelta brillante quella di andare a capo sul "-". In pratica nel copia-incolla si perde un pezzo della URL che quindi risulta errata (di fatti non viene identificato lo scope associato - anche se qualcuno dice sia "normale").
martedì 10 luglio 2012
domenica 20 maggio 2012
SMF forum fix
Mi sono ritrovato ad "ereditare" un backup SQL di un forum SMF.
Rimesso in piedi il tutto e installata qualche mod il tutto è "esploso" al primo update di SMF in quanto le mod installate non combaciavano con quanto riportato nel DB (Le mod installate nell'installazione originale non erano state reinstallate in quanto avevo solo il backup SQL e non i file).
Mi sono quindi trovato con un forum che funzionava ma con le mod disabilitate e l'impossibilità di installarne altre in quanto il DB conteneva già queste modifiche. Mi sono quindi posto il problema di come "sistemare" questo accrocchio.
ATTENZIONE tutto quello che segue è capacissimo, con una virgola fuori posto, ma anche senza, di segarvi non solo il database ma tutta la macchina. NON SCASSATEMI I CABASISI SE VI PIALLATE LA MACCHINA E NON AVETE UN BACKUP!
Fatta questa doverosa premessa, l'idea di base è esportare il database attuale ed importarlo in una nuova installazione SMF. Poichè il DB attuale ha più tabelle (con in alcuni casi più colonne) del DB pulito ho dovuto inventarmi un sistema per fare il tutto...
Dato il database di partenza FORUM e il database nuovo che chiameremo BACKUP (su installazione fresca dell'ultima versione di SMF) procediamo a leggere i nomi dei campi di una tabella, ad esportare i dati di questi soli campi dal DB di partenza e a metterli in un file di nome fix_$nome_tabella_table.sql
smf_fix_table (da chiamare con il nome tabella per parametro)
#!/bin/sh
list=`echo "describe $1;"| mysql -s backup -u backupuser --password='backuppassword' | awk '{print$1}'`
output="select "
count=0
for i in $list
do
if [ $count -gt 0 ]; then
output=$output","
fi
output=$output" $i"
count=1
done
output=$output" from $1 into outfile 'fix_$1_table.sql';"
echo $output | mysql -s forum -u forumuser --password='forumpassword'
Questo script a sua volta verrà chiamato ricorsivamente da uno script che agirà sulle tabelle, chiama lo script precedente, copia il file nella cartella del DB di backup, tronca la tabella e carica il dump nella tabella corrispondente del db di backup, infine elimina i file di dump (per permettere più agevolmente una serie di drop database, create database, grant, import, etc, necessari a sperimentare ripetutamente per ottenere qualcosa di funzionante) :
smf_fix
#!/bin/sh
list=`echo "show tables;"| mysql -s backup -u backupuser --password='backupuser' | awk '{print$1}'`
for i in $list
do
filename="fix_"$i"_table.sql"
./smf_fix_table $i
mv /var/lib/mysql/forum/$filename /var/lib/mysql/backup/
echo "truncate table $i" | mysql -s backup -u backupuser --password='backuppassword'
echo "load data local infile '/var/lib/mysql/backup/$filename' into table $i" | mysql -s backup -u backupuser --password='backuppassword'
rm /var/lib/mysql/vtrspbackup/fix*
done
Rimesso in piedi il tutto e installata qualche mod il tutto è "esploso" al primo update di SMF in quanto le mod installate non combaciavano con quanto riportato nel DB (Le mod installate nell'installazione originale non erano state reinstallate in quanto avevo solo il backup SQL e non i file).
Mi sono quindi trovato con un forum che funzionava ma con le mod disabilitate e l'impossibilità di installarne altre in quanto il DB conteneva già queste modifiche. Mi sono quindi posto il problema di come "sistemare" questo accrocchio.
ATTENZIONE tutto quello che segue è capacissimo, con una virgola fuori posto, ma anche senza, di segarvi non solo il database ma tutta la macchina. NON SCASSATEMI I CABASISI SE VI PIALLATE LA MACCHINA E NON AVETE UN BACKUP!
Fatta questa doverosa premessa, l'idea di base è esportare il database attuale ed importarlo in una nuova installazione SMF. Poichè il DB attuale ha più tabelle (con in alcuni casi più colonne) del DB pulito ho dovuto inventarmi un sistema per fare il tutto...
Dato il database di partenza FORUM e il database nuovo che chiameremo BACKUP (su installazione fresca dell'ultima versione di SMF) procediamo a leggere i nomi dei campi di una tabella, ad esportare i dati di questi soli campi dal DB di partenza e a metterli in un file di nome fix_$nome_tabella_table.sql
smf_fix_table (da chiamare con il nome tabella per parametro)
#!/bin/sh
list=`echo "describe $1;"| mysql -s backup -u backupuser --password='backuppassword' | awk '{print$1}'`
output="select "
count=0
for i in $list
do
if [ $count -gt 0 ]; then
output=$output","
fi
output=$output" $i"
count=1
done
output=$output" from $1 into outfile 'fix_$1_table.sql';"
echo $output | mysql -s forum -u forumuser --password='forumpassword'
Questo script a sua volta verrà chiamato ricorsivamente da uno script che agirà sulle tabelle, chiama lo script precedente, copia il file nella cartella del DB di backup, tronca la tabella e carica il dump nella tabella corrispondente del db di backup, infine elimina i file di dump (per permettere più agevolmente una serie di drop database, create database, grant, import, etc, necessari a sperimentare ripetutamente per ottenere qualcosa di funzionante) :
smf_fix
#!/bin/sh
list=`echo "show tables;"| mysql -s backup -u backupuser --password='backupuser' | awk '{print$1}'`
for i in $list
do
filename="fix_"$i"_table.sql"
./smf_fix_table $i
mv /var/lib/mysql/forum/$filename /var/lib/mysql/backup/
echo "truncate table $i" | mysql -s backup -u backupuser --password='backuppassword'
echo "load data local infile '/var/lib/mysql/backup/$filename' into table $i" | mysql -s backup -u backupuser --password='backuppassword'
rm /var/lib/mysql/vtrspbackup/fix*
done
Il forum che ne risulta è per quanto ho potuto verificare funzionante, usa TUTTE le login dell'originale (eliminando la login admin che avete creato in fase di installazione).
Spero qualcuno si eviti qualche ora di craniate nel muro.
giovedì 19 gennaio 2012
mysql e lettere accentate...
Problemi di database di tutti i giorni, o quasi...
scrivo è in un sito e nel db mi trovo "è", sul sito mi ritrovo correttamente è, ma cercando di ripristinare il backup del DB su altro pc impazzisce tutto.. aiut.
cerca qui, cerca li trovo un articolo interessante: http://forums.mysql.com/read.php?103,164542,182402#msg-182402
Riassumendo: se cerchiamo "è" nella tabella caratteri iso 8859 (standard latin1 usato da mysql) troviamo che viene codificato come 00E8. Nella tabella UTF8 invece viene codificato come C3 A8. Tornando alla tabella latin1 troviamo che C3 è la codifica latin1 di à mentre E8 è uguale, chi l'avrebbe mai detto, a ¨.
Quindi appurato che il nostro db salva una codifica unicode a 2 byte e in esportazione scrive due caratteri latin1 da 1 byte.. ora c'è da capire come risolvere, ma è un bel passettino avanti.
scrivo è in un sito e nel db mi trovo "è", sul sito mi ritrovo correttamente è, ma cercando di ripristinare il backup del DB su altro pc impazzisce tutto.. aiut.
cerca qui, cerca li trovo un articolo interessante: http://forums.mysql.com/read.php?103,164542,182402#msg-182402
Riassumendo: se cerchiamo "è" nella tabella caratteri iso 8859 (standard latin1 usato da mysql) troviamo che viene codificato come 00E8. Nella tabella UTF8 invece viene codificato come C3 A8. Tornando alla tabella latin1 troviamo che C3 è la codifica latin1 di à mentre E8 è uguale, chi l'avrebbe mai detto, a ¨.
Quindi appurato che il nostro db salva una codifica unicode a 2 byte e in esportazione scrive due caratteri latin1 da 1 byte.. ora c'è da capire come risolvere, ma è un bel passettino avanti.
Iscriviti a:
Post (Atom)