Test Joomla su database PostgreSQL

[alexred]

il driver PostgreSQL è stato committato in extremis:
https://github.com/joomla/joomla-cms/commit/f6de2e78bfcf18d216e5c0470f006a1e54b6a06d

dovrebbe quindi essere presente nella versione 3.0 Beta1 che arriverà a breve

[alexred]

ho provato ad installare la Beta1 disponibile oggi, sempre selezionando il database PostgreSQL, ma mi continua a rimandare a fine installazione all'ultima pagina con i riepilogo dei dati.

Forse dovremmo riprovare ad installare la versione alpha1 di Pongelli che sembrava installarsi correttamente, per capire se è cambiato qualcosa sul server di test... se non si installasse più nemmeno quella...

[Ladyj]

Ho provato ora con Joomla! 3.0.1, l'installazione arriva correttamente fino in fondo.
Sto usando PostgreSQL 9.2.
L'unica difficoltà che ho dovuto affrontare è stata la modifica del driver, {JOOMLA_HOME}/libraries/joomla/database/driver/postgres.sql, alla riga 115:

$dsn = "host={$this->options['host']} port=5433 dbname={$this->options['database']} user={$this->options['user']} password={$this->options['password']}";

Il mio db non è in ascolto sulla porta standard, la 5432.

Buon PostJoom a tutti!

Mariella

[alexred]

Ciao Ladyj,
grazie per la segnalazione.

Ti chiedo cortesemente se puoi effettuare questi test per verificare se ora è tutto ok:
http://forum.joomla.it/index.php/topic,168247.0.html

[gpongelli]

Ciao Mariella,
grazie per la segnalazione
Il file a cui fai riferimento è un php e non sql
ho realizzato diverso tempo fa una pull request sul CMS per aggiungere la personalizzazione della porta, dalla fase di installazione alla successiva modifica nel pannello di configurazione, ma purtroppo non è stata mai inserita nel CMS.
Riproverò ad aggiornarla in seguito nella speranza che venga inclusa.

Buona giornata

[Ladyj]

Si si, php, ho sbagliato a scrivere.

Per quanto riguarda l'errore 4, sono perplessa, in questo senso: secondo me joomla 3.0.1 con mysqli funziona per puro sbaglio  . Mi spiego meglio. Il tuo codice e quello del driver mysqli sono allineati.
Sia il tuo postgres.sql righe 674-679, sia il mysqli.php righe 531-535 buttano a video un messaggio con gli errori del dbms.

MySQLi non manda niente a video perchè il driver (o direttamente il db) troncano il valore a 255 caratteri così, per partito preso. In pratica mysql non da errore, postgres (secondo me giustamente) invece si.

Ho controllato la select che arriva a mysql con la mysqli_query, il campo titolo non viene ripulito prima dal codice con una substr per esempio, arriva al db una stringa oltre i 255 caratteri, e mysql ne salva solo i primi 255. Ho controllato, Mysql si composta così anche col vecchio driver, il mysql_query per intenderci.

[gpongelli]

rispondo un po in ritardo...

Per quanto riguarda l'errore 4, sono perplessa, in questo senso: secondo me joomla 3.0.1 con mysqli funziona per puro sbaglio  . Mi spiego meglio. Il tuo codice e quello del driver mysqli sono allineati.
Sia il tuo postgres.sql righe 674-679, sia il mysqli.php righe 531-535 buttano a video un messaggio con gli errori del dbms.

MySQLi non manda niente a video perchè il driver (o direttamente il db) troncano il valore a 255 caratteri così, per partito preso. In pratica mysql non da errore, postgres (secondo me giustamente) invece si.

Ho controllato la select che arriva a mysql con la mysqli_query, il campo titolo non viene ripulito prima dal codice con una substr per esempio, arriva al db una stringa oltre i 255 caratteri, e mysql ne salva solo i primi 255. Ho controllato, Mysql si composta così anche col vecchio driver, il mysql_query per intenderci.

purtroppo è proprio come hai scritto, "funziona per puro sbaglio"


MySQL tronca la stringa a 255 caratteri, senza segnalare nulla, postgresql lo fa perché stai tentando di scrivere più caratteri di quanti lui al massimo si aspetta!


adesso non so precisamente qual'è il codice che genera l'errore, ma sicuramente sarà per uno dei campi creati come "character varying(255)", il che significa un tipo che accetta una stringa da 0 a 255 caratteri, non di più.
Il concetto che può trarre in inganno è proprio del "tipo", postgresql è tipizzato e controlla i tipi di cosa si sta inserendo, mysql non mi pare...la soluzione è semplice, prendere il codice del CMS che genera questo errore e troncarla a 255 (o 254, non ricordo se postgresql ha bisogno dell'ultimo carattere di '\0' come terminatore di stringa, alla C-style visto che postgresql è scritto proprio in C) e poi passarla al db, qualunque esso sia.
Continuerò a dare un'occhiata alla vostra lista, tempo permettendo


Gabriele.

[Ladyj]

Cosa intendi con "prendere il codice del CMS che genera questo errore e troncarla a 255". Codice del componente Joomla! o del tuo driver?
Il problema è che mysql è eccessivamente gentile (un dbms deve dare errore in questi casi, non lasciarmi l'illusione di aver salvato tutto), e chissà quanto codice inconsapevolmente bucato c'è in circolazione nel core o in componenti/moduli del jad che funzionano solo perchè mysql non si scompone e non da errore. Mettigli sotto postgres e comincerebbero a dare i numeri. Lo farebbero anche con Oracle, ci lavoro tutti i giorni e ti assicuro che se un valore non ci sta in una colonna, non salva niente e da errore.

I patcherei il driver, mettendo lì il codice per la truncate. Se ti va l'idea butto giù un po' di codice, poi vedi tu. Spulcio anche il resto della lista ... se riesco ad imboscarmi al lavoro o a resistere fino a tardi la sera  .

A postgres ci tengo. MySQL, da quando mamma Oracle ci ha messo sopra il cappello, lo considero fuori dal mondo open.

Ciao

[gpongelli]

scusami se rispondo in ritardo ma ultimamente ho problemi col cellulare 

Cosa intendi con "prendere il codice del CMS che genera questo errore e troncarla a 255". Codice del componente Joomla! o del tuo driver?

nel senso che bisogna individuare il componente che genera l'errore, quindi il suo model, e correggerlo troncando sul nascere la stringa a 255 caratteri, lì e in tutti gli altri casi.

Il problema è che mysql è eccessivamente gentile (un dbms deve dare errore in questi casi, non lasciarmi l'illusione di aver salvato tutto), e chissà quanto codice inconsapevolmente bucato c'è in circolazione nel core o in componenti/moduli del jad che funzionano solo perchè mysql non si scompone e non da errore. Mettigli sotto postgres e comincerebbero a dare i numeri. Lo farebbero anche con Oracle, ci lavoro tutti i giorni e ti assicuro che se un valore non ci sta in una colonna, non salva niente e da errore

concordo su tutti i fronti    [size=78%]![/size]

I patcherei il driver, mettendo lì il codice per la truncate. Se ti va l'idea butto giù un po' di codice, poi vedi tu. Spulcio anche il resto della lista ... se riesco ad imboscarmi al lavoro o a resistere fino a tardi la sera  .

A postgres ci tengo. MySQL, da quando mamma Oracle ci ha messo sopra il cappello, lo considero fuori dal mondo open.

il problema di troncare all'interno del driver può essere interessante se uno ragiona pensando "lì sicuramente questa stringa ci passa, da qualsiasi parte provenga la correggo e sto sicuro/a"!
il problema è che sicuramente verrà chiamata una generica insertObject e inserire lì un controllo aggiuntivo sulla lunghezza del possibile campo (in tutto saranno una decina di colonne varchar(255) sul numero sterminato di colonne esistenti nel db di joomla, senza considerare all'interno del driver bisognerebbe prima sapere qual'è il tipo della colonna, non ha senso troncare una data o un intero) potrebbe rallentare l'esecuzione di ogni insertObject e, altro lato della medaglia, troncare a 255 dei campi che invece accettano più caratteri come un text 
spero di essermi spiegato un po meglio




buona serata 

[Ladyj]

E' la punta di un iceberg-rogna sui tipi questa storia ... 
Ho appena dato un occhio all'errore 5. C'è ancora. L'update in errore è questo:

UPDATE "j301_finder_links"
   SET "route"              = 'index.php?option=com_content&view=category&id=9',
       "title"              = 'Uncategorised',
       "description"        = '',
       "indexdate"          = NOW(),
       "state"              = 1,
       "access"             = 1,
       "language"           = '*',
       "type_id"            = 1,
       "object"             = 'O:19:"FinderIndexerResult":18:{s:11:"',
       "publish_start_date" = '1970-01-01 00:00:00',
       "publish_end_date"   = '1970-01-01 00:00:00',
       "start_date"         = '2011-01-01 00:00:01',
       "end_date"           = '1970-01-01 00:00:00',
       "list_price"         = '',
       "sale_price"         = ''
 WHERE link_id = 1

E l'errore è:
ERROR:  invalid input syntax for type numeric: ""
LINE 15:        "list_price"         = '',
                                       ^

********** Errore **********

ERROR: invalid input syntax for type numeric: ""
Stato SQL: 22P02
Carattere: 674

Errore giustissimo e sacrosanto, list_price è un number, non ci puoi mettere una stringa. Mettendo uno 0 al posto dei '' l'errore si sposta su sale_price. Facendo la stessa cosa l'update viene eseguita correttamente.

Ora, ho passato la stessa update a MySQL (correggendo solo i quote) e indovina? Se l'è presa e ingoiata, tutto liscio, il '' è diventato un bello 0. Per capire da dove venisse la traduzione in 0 ho smontato gli orpelli della colonna list_price su mysql. Ho tolto il not null, l'attributo unsigned e il default a 0. Niente, mysql traduce '' in 0 da solo. Per poter mettere null nella colonna l'update deve essere "= null".

Insomma MySQL è un dbms creativo mentre postgres no (e meno male! sulla base di cosa '' diventa 0?).
E' lo stesso problema del punto 4, servito con una salsa diversa.
Mentre punto 6 è lo stesso errore, '' in list_price e list_sale.

I trigger? A naso non servono, sono a valle, il controllo sui tipi avviene a monte.
Lo so che non ci si può mettere a fare truncate a tappeto tu tutti i valori. Ma per distinguere in casi in cui fare dei controlli da quelli in cui non servono possono tornare utili queste function del driver postgres:

pg_field_type()
pg_field_prtlen()
pg_field_name()
pg_field_type_oid()

[gpongelli]

Mysql è un dbms decisamente creativo, gioca molto sui cast impliciti IMHO, così per l'esempio che hai riportato il passaggio da '' a 0 è "semplicemente" legato al tipo della colonna destinazione, essendo intero converte una stringa vuota in zero, mentre per inserire il null deve essere esplicito.
Qualcuna di quelle funzioni le ho usate nelle classi exporter/importer, ma anche qua le vedo poco adatte e performanti per il driver in se, proprio perché quest'ultimo non si può mettere a controllare tutti i valori passati se corrispondono al tipo.
Il driver il suo lavoro lo fa, e anche bene visti gli errori XD , il problema sta in chi sviluppa componenti per il CMS che usano delle tabelle senza conoscere i tipi inclusi
L'unica cosa che magari guarderei a fondo è la creazione della query da parte del model, in qualche chiamata c'è l'aggiunta di campi che altrimenti assumerebbero il valore di default e invece, visto che sono presenti nella query (aggiunti non so da quale funzione e riempiti con errati valori di default) provocano il danno un po ovunque.
Se riesco questo weekend dò un'occhiata

Gabriele.

[gpongelli]

Per pura curiosità ho spulciato al volo il codice, trovando la chiamata e la sua soluzione XD
La classe è FinderIndexerDriverPostgresql e l'ho creata io decisamente di fretta poco prima che venisse incluso il driver anche nel CMS, alla riga 165 e 166 ho valorizzato i campi della query di update senza controllare come ho invece fatto alle righe 138-139
Con quel semplice controllo si correggono questi errori a monte
O altrimenti potrebbe andare bene anche un cast a intero e si risolve.
La domanda però sorge spontanea: chi è che popola list_price con '' invece che con zero?

Buona giornata

[Ladyj]

Trovato!

A mettere gli '' è la $db->quote($item->list_price)); a riga 165 del file postgresql.php sotto {JOOMLA}/administrator/components/com_finder/helpers/indexer/driver.

$item->list_price arriva null quando lancio lo Smart Search Indexer. Il methodo quote che viene usato è quello del file driver.php sotto {JOOMLA}/libraries/joomla/database riga 1376 che fa una cosa molto semplice:

    public function quote($text, $escape = true)
    {
        return '\'' . ($escape ? $this->escape($text) : $text) . '\'';
    }

Vedi? Mette gli apici d'ufficio. Altra cosa che a MySQL piace tanto, apici a pioggia

[gpongelli]

È il punto che avevo individuato stamattina
In serata correggo e mando la pull request
Avanti al prossimo bug

Grazie per la partecipazione

[gpongelli]

pull request inviata
chi volesse provare questa versione, dal link deve premere sulla scheda "Files changed" quindi il pulsante "view file @..." , a seguire il pulsante "Raw" e copiare tutto sul file che avete localmente

[Ladyj]

Bene.
Il bug 7 penso sia riconducibile ai punti precedenti.
L'8 invece è un altra parrocchia.
A postgresql arriva questa istruzione:

SELECT u.name, count(cd.language) as counted, MAX(cd.language='*') as all_languages
FROM odm2e_users AS u
LEFT JOIN odm2e_contact_details AS cd ON cd.user_id=u.id
LEFT JOIN odm2e_languages as l on cd.language=l.lang_code
WHERE EXISTS (SELECT * from odm2e_content as c where  c.created_by=u.id) AND (l.published=1 or cd.language='*') AND cd.published=1
GROUP BY u.id
HAVING (counted !=1 OR all_languages=1) AND (counted !=1 OR all_languages=0)

Questa roba lo manda in palla per parecchi versi:  Il MAX, l'having in basso.
Ti giro lo stack delle chiamate in allegato



[allegato eliminato da un amministratore essendo vecchio più di un anno]

[bismark2005]

Come è la situazione di Joomla e postgresq? Joomla supporta postgresql?