domenica 21 dicembre 2014

Calendario dell'Avvento ITPUG: 21 Dicembre

Questa mattina Denis batte tutti sul tempo e pubblica sulla mailing list un articolo veramente piacevole da leggere e ben dettagliato su come usare l'estensione pg_partman che consente di automatizzare molti dei compiti del partizionamento in PostgreSQL.
L'articolo di Denis fornisce un esempio pratico e illustra anche alcuni dei problemi che potrebbero insorgere nell'utilizzo del partizionamento.

sabato 20 dicembre 2014

Calendario dell'Avvento ITPUG: 20 Dicembre

Vorrei introdurre una utility con la quale sto spendendo un po' di tempo e che, anche se non direttamente collegata a PostgreSQL, può semplificare la gestione di un database: sqitch.
Sqitch funziona con molti database, fra i quali ovviamente PostgreSQL, producendo degli script sql che vengono usati per fare il deploy/aggiornamento/test di un database.
Sqitch concettualmente funziona un po' come un repository Git/hg:
  • si installa uno schema "sqitch" nel database sotto controllo;
  • si usa questo schema per memorizzare le modifiche effettuate e "firmate" con un hash crittografico
Il tutto è trasparente all'utente, che usa il solo comando "sqitch" un po' come si usa git (e molti comandi e il loro output sono simili, come ad esempio log, status, add).
Attenzione però che sqitch non sostituisce un sistema di controllo delle versioni, quindi è buona norma usare sqitch tenendo comunque gli script SQL sotto controllo delle versioni.

Ecco un rapidissimo esempio per la generazione di due tabelle in un database (demodb) esistente.

  • crare un nuovo progetto e definire il database

% sqitch --engine pg init itpug
% sqitch target add itpug db:pg://luca:pwd@localhost/demodb

così facendo si crea un progetto "itpug" e si definisce che quando ci si riferisce al database "itpug" si punta in realtà a demodb.

  • si aggiunge lo script per la prima tabella

% sqitch add authors -m "Tabella autori"                                                        
Created deploy/authors.sql
Created revert/authors.sql
Created verify/authors.sql
Added "authors" to sqitch.plan
% echo "CREATE TABLE authors( pk serial NOT NULL, name text NOT NULL, primary key(pk));" > deploy/authors.sql
% echo "DROP TABLE authors CASCADE;" > revert/authors.sql


così facendo sqitch crea tre script sql (vuoti) per il deploy, l'undeploy e la verifica (qui lasciato vuoto).

  • si crea una tabella con dipendenza dalla precedente, così da informare sqitch in che ordine le modifiche al database vanno applicate

% sqitch add posts --requires authors -m "Tabella dei post"                                      
Created deploy/posts.sql
Created revert/posts.sql
Created verify/posts.sql
Added "posts [authors]" to sqitch.plan
% echo "CREATE TABLE posts( pk serial NOT NULL, content text , authors_pk integer, primary key(pk), foreign key(authors_pk) references authors(pk) );" > deploy/posts.sql
% echo "DROP TABLE posts;" > revert/posts.sql


  • deploy del database, e si nota come sqitch si colleghi a demodb per creare le tabelle nel giusto ordine.

% sqitch deploy itpug                                                                            
Adding registry tables to itpug
Deploying changes to itpug
  + authors .. psql:deploy/authors.sql:1: NOTICE:  CREATE TABLE will create implicit sequence "authors_pk_seq" for serial column "authors.pk"
psql:deploy/authors.sql:1: NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "authors_pkey" for table "authors"
ok
  + posts .... psql:deploy/posts.sql:9: NOTICE:  CREATE TABLE will create implicit sequence "posts_pk_seq" for serial column "posts.pk"
psql:deploy/posts.sql:9: NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "posts_pkey" for table "posts"
ok


Da qui in avanti si può usare "log" o "status" per sapere in che stato ci si trova, se ci sono script non ancora inviati al server, ecc.
Occorre però specificare sempre a quale database si fa riferimento (che qui è stato denominato itpug per comodità). Se ad esempio eseguiamo status fra due deploy si avrebbe:

% sqitch status itpug                                                                            
# On database itpug
# Project:  itpug
# Change:   173fb5f9cf9f5048e5b2baf6e6699984b4fdb9fe
# Name:     authors
# Deployed: 2014-12-18 11:33:22 +0100
# By:       Luca Ferrari,,,
#
Undeployed change:
  * posts



notare come l'output sia simile a quello di un rcs distribuito, anche se qui git/hg/bzr non sono nemmeno stati toccati.


Ultimissima cosa: gli script crewti da sqitch non sono "vuoti" ma contengono  informazioni su come gestire le dipendenze. Di conseguenza, sovrascrivere tali script come ho fatto nel passo 3 è sbagliato. Meglio quindi editarli nel proprio editor preferito. Per meglio comprendere, consideriamo di aggiungere un'altra tabella con la dipendenza dalle altre due:

% sqitch add statistics --requires authors --requires posts                                      
Created deploy/statistics.sql
Created revert/statistics.sql
Created verify/statistics.sql
Added "statistics [authors posts]" to sqitch.plan

% cat deploy/statistics.sql                                                                      
-- Deploy statistics
-- requires: authors
-- requires: posts

BEGIN;

-- XXX Add DDLs here.

COMMIT;


Ecco quindi che quei commenti sql all'inizio del file indicano a sqitch come procedere.

Se si vuole esplorare come sqitch gestisce il database e la sua storia si può partire dalla tabella sqitch.changes.

Me @ Planet PostgreSQL

This is my first attempt to appear on Planet PostgreSQL.
I'm Luca, the current president of the Italian PostgreSQL Users' Group (ITPUG) and I'm a PostgreSQL addicted.
Unluckily I'm currently not using PostgreSQL in a day-by-day job, but I'm following the evolution of the project and using it wherever is possible.
I hope to able to contribute to the community somehow.

venerdì 19 dicembre 2014

Calendario dell'Avvento ITPUG: 19 Dicembre

Per l'articolo di oggi mi faccio aiutare da un post passato in -advocacy per fare qualche considerazione.
PostgreSQL potrebbe essere il quarto piu' popolare database del pianeta. Dico potrebbe perché ovviamente non ha senso la misura fatta da dbengines.com. Almeno non per me.
Non si tratta infatti di una misura tecnica o tecnologica, quanto piu' sociale.
 
Ora leggendo la metodologia applicata si vede che la metrica tiene presente  quanto si parla nel web di un database. La differenza di punteggio fra PostgreSQL e gli altri tre prodotti che lo precedono è sconvolgente. Ma come si può notare i posti fuori dal podio hanno uno score non troppo dissimile e, a mio avviso, tutti una buona qualità tecnica.
Cosa significa questo in soldoni? Che chi usa PostgreSQL preferisce parlare di cose tecniche e non filosofeggiare. E ciò è bene fino a quando non ci si scontra con queste classifiche, che inevitabilmente potrebbero portare qualcuno a fare la scelta sbagliata su indici forse poco attendibili. 

Tutto questo per ricordare a noi tutti che quanto piu' materiale siamo in grado di produrre e diffondere su PostgreSQL, tanto piu' il database continuerà a guadagnare in popolarità, e tanto piu' sarà facile (per noi) avere a che fare con installazioni PostgreSQL.

giovedì 18 dicembre 2014

Calendario dell'Avvento ITPUG: 18 Dicembre

Personalmente uso Emacs per quasi tutto, eccetto che per collegarmi ad
un database PostgreSQL.
Non che Emacs non possa farlo, ma semplicemente mi trovo meglio con psql per svariate ragioni, compreso il fatto che a volte devo accedere a macchine che non hanno Emacs installato (e non sono raggiungibili da macchine con Emacs installato). Ad ogni modo Emacs dispone di una serie di modi sql-* per svariati database, fra i quali ovviamente PostgreSQL.
Ora perché diavolo qualcuno dovrebbe collegarsi a un database tramite Emacs? Semplicemente perché inglobare il client dentro all'editor facilita lo scambio dati fra script, server, email, e qualunque altro buffer abbiate aperto (inclusi i commit per le versioni)!

Riporto una minimale configurazione per un ambiente con due database (ovviamente username e password sono inventati):

(add-hook 'sql-interactive-mode-hook
 (lambda ()
  (toggle-truncate-lines t)))

(setq sql-connection-alist
'((TEST (sql-product 'postgres)
    (sql-port 5432)
    (sql-server "localhost")
    (sql-user "demo")
    (sql-password "demo")
    (sql-database "demodb"))
 (PROD (sql-product 'postgres)
    (setq sql-port 5432)
    (sql-user "demo")
    (sql-password "demo")
    (sql-database "demodb") ) ) )


(defun pg-connect (which)).
  (interactive "SQuale connessione database?" )
    (setq sql-product 'postgres)
    (let ()
     (message "Connessione al database %s" which)
      (sql-connect which ) ) )


Anzitutto si abilita la modalità "linee lunghe", perché visualizzare l'output delle query con le andate a capo è abbastanza fastidioso. Poi si definiscono due database, nominati TEST e PROD, con i relativi parametri di connessione. Si possono definire quante connessioni si vuole.
Infine la funzione pg-connect chiede all'utente a quale database collegarsi: M-x pg-connect e poi si inserisce il nome del database (TEST o PROD).
Dopodiché emacs apre il prompt (psql) del database in un buffer separato.

Notare che questa configurazione funziona su Emacs 24.4.1 ma mi ha
dato qualche grattacapo su 24.3

Esce PostgreSQL 9.4

Sotto Natale il PostgreSQL Global Development Group ci regala la nuova versione stabile del fantastico ORDBMS: PostgreSQL 9.4.

mercoledì 17 dicembre 2014

A few ridicolous (to me) Perl requests

Usually I don't get personal on blogging and commenting: everyone is free to express herself on the net about pretty much any subject. And I'm not getting personal on this set of entries too, but I have to spend a few words on a Perl blogger that is requesting loudly for a set of shortcuts in the language that make no sense at all.

One is about the versioning of the Perl language: stating that Perl 6 is a different beast from Perl 5 is quite easy. But pretending to have different numbering of both versions is awkward. For external developers Perl 6 is the new version of the Perl language, and this is the thruth. The fact that Perl 6 has evolved as a more complex beast than a "simple language improvement" is another fact, but having to number them independently will cause a lot of confusion.

Another issue is about enabling use warnings; silently when specifying use 5.x;. While I understand that it would be much more easy to use a single line pragma, the author does not realize that there is a lot of legacy code that do not explicitly negates warnings since they were not enabled by default. And keeping backward compatibility is really important.
I don't want my programs to behave strangely just because a future version of Perl let me write simpler code: I just want to write simpler code in the future, without having to constantly refactor old code.

On the same mindset if the request to have package to return automatically a true value. Again, the point is valid and I believe in the future could be a reasonable way of programming, but it is not the right choice for legacy code. And moreover, it does not make sense at all when developers will use /package/ multiple times within the same file (because Perl is not Java, right?).