This challenge was trickier than you may first think because of the following reasons:

1. I don’t have manual access to the Postgres DB, I can only run a Rails console that connects to it
2. The Postgres DB and the WordPress Blog are installed on two different servers that are not in the same LAN.

Here is how I did the job, of course, using Perl as my weapon was the only option I considered, and I’m glad of it.

First step : exporting the data, JSON FTW

As the only way I had to handle the data source was a Rails console, I chose first to use YAML for exporting the data into a file, but I wasn’t able to parse it with Perl then, because of badly-written multiline scalars (I don’t know whose fault it is, either Ruby or Perl YAML modules, but it didn’t work out of the box).

Then I tried JSON:

# dump_posts.rb (to be run with ./script/runner -e production)
posts = MyRailsPost.find(:all)
f = File.new("/tmp/posts.json", 'w')
f.write(posts.to_json)
f.close

I then uploaded the json file to my second server, where I have access to the WordPress DB and started writing an importer.

From a JSON file to a WordPress DB

Now I have my data in JSON format, I can write a Perl script that will parse it and insert each post item found in the WordPress “wp_posts” table.

First, I’ll write a Coat::Persistent class to handle WordPress blog posts:

package WPPost;
use Coat;
use Coat::Persistent
    table_name => "wp_posts",
    primary_key => "ID";

has_p post_author => (isa => 'Int', required => 1);
has_p post_date => (isa => 'DateTime', coerce => 1);
has_p post_excerpt => (isa => 'Str');
has_p post_content => (isa => 'Str');
has_p post_title => (isa => 'Str');
has_p post_name => (isa => 'Str');

sub BUILD {
    my $self = shift;
    my $class = ref($self);
    $class->dbh->do('SET NAMES utf8') or die $!;
}

Coat::Persistent->disable_internal_sequence_engine();
__PACKAGE__->map_to_dbi(mysql => "MYDATABASE", "DBUSER", "DBPASS")

Please note that we tells DBD::mysql to send data in utf8 (SET NAMES utf8), this is very important, if we don’t, we’ll endup in WordPress with a mess of utf8/latin1 crap.

The post_date field will be set with Rails’ created_at attribute, and it might be in a different format than YYYY-MM-DD HH:MM:SS, so I’ll write subtypes and coercions to handle that cleanly:

use Coat::Types;
use Coat::Persistent::Types;

subtype 'DateTimeSec'
    => as 'Str'
    => where { /\d{4}-\d\d-\d\d \d+:\d+:\d+\.\d+/ };

subtype 'DateTimeWithTZ'
    => as 'Str'
    => where { /\d{4}-\d\d-\d\dT\d\d:\d\d:\d\d\+\d\d:\d\d/ };

subtype 'DateTimeWithT'
    => as 'Str'
    => where { /\d{4}-\d\d-\d\dT\d\d:\d\d:\d\d/ };

coerce 'DateTime'
    => from 'DateTimeWithTZ'
    => where { s/\+.+$//; s/T/ /; return $_ };

coerce 'DateTime'
    => from 'DateTimeWithT'
    => via { s/T/ /; return $_ };

coerce 'DateTime'
    => from 'DateTimeSec'
    => via { s/\.\d+$//; return $_ };

Now, I have all I need, I can write the scrit:

#!/usr/bin/perl
use strict;
use warnings;

# slurping my JSON file
open FIC, '< ', $ARGV[0] or die $!;
my @lines = ;
close FIC;
my $content = join '', @lines;

# processing posts
my $data = from_json($content);
for my $post (@$data) {

    my $p = $post->{rails_post_class}; # JSON output in Rails works this way

    my $wp = WPPost->create(
        post_author => 1,               # admin
        post_date => $p->{created_at},  # coercion will occur here
        post_excerpt => $p->{excerpt},
        post_content => $p->{body},
        post_title => $p->{title},
        post_name => $p->{permalink},
    );
    print "+ ".$wp->post_title." -> #".$wp->ID."\n";
}

Note: you can consider this post as the first-and-last item of my 2009 Perl Advent Calendar ;)

Related posts:

1. Coat is alive (sort of) Coat is a module I wrote when I needed Moose...
2. How to Identify a Good Perl Programmer, part 2 Superman by Dunechaser Chromatic has published a set of questions...
3. Perl Dancer meeting #1 As explained on the mailing list, we had the idea...

Voila une bonne chose de faîte, c’est en quelque sorte une manière de boucler la présentation des Journées Perl 2009 et le problème technique qui s’était posé.

Cette version propose les changements suivants :

• Mention de la licence “perl” dans Makefile.PL (bug #46912)
• Ajout d’un fichier CHANGES (bug #46913)
• Support de l’option store_as pour les attributs persistants
• Module Coat::Persistent::Types::MySQL qui fournit les types et les coercitions correspondantes pour les types de données MySQL Date et DateTime

Voici un petit exemple de code qui montre les possibilités de cette nouvelle version :

Reprenons notre chameau utilisé pour illustrer la présentation, nous allons lui ajouter une date de création, que l’on souhaitera manipuler sous forme de timestamp dans le code de l’application, et stocker sous forme de MySQL DateTime dans la base.

package Camel;
use Coat;
use Coat::Persistent;
use Coat::Persistent::Types::MySQL;

has_p name => (isa => 'Str');
has_p age => (age => 'Int');

has_p created_at => (
  is => 'rw',
  isa => 'Int',
  store_as => 'MySQL:DateTime',
);

Jouons maintenant avec cette classe et observons le comportement de l’accesseur created_at :

Perl> use Camel
Perl> my $c = Camel->find(3)
$Camel1 = Camel=HASH(0x9967028);

Perl> $c->created_at(time)
1245413521

Perl> $c->save
3

Maintenant regardons le contenu de la base de données pour le camel d’id 3

sqlite> select created_at from camel where id = 3;
2009-06-19 14:12:01

Au passage, on notera un effet de bord assez apréciable de cette double coercition entre type réel et type de stockage : on peut très bien assigner une valeur formattée à created_at au lieu d’un timestamp. La coercition interviendra dans l’autre sens, et notre objet aura toujours un timestamp :

Perl> $c->created_at('1979-11-20 20:20:00')
311973600

Mission complete j’ai envie de dire ;)

Update: Suite à la remarque de oz dans les commentaires, j’ai publié la version 0.210 qui propose un module Coat::Persistent::Types afin de définir tout plein de types de Date et les coercitions qui vont bien

Related posts:

1. De la bonne façon de manipuler le temps avec Coat::Persistent Soit la situation suivante : vous avez une classe qui...
2. Coat Persistent La famille de Coat s’agrandit, voici un premier essai de...
3. Nouvelle version de Coat::Persistent : 0.104 En travaillant sur mes slides pour FPW 2009, je me...

Comment faire pour pouvoir utiliser côté Perl, un timestamp et stocker en base une date formatée pour la base de données ?

C’est le problème que je me suis posé récemment avec Coat::Persistent. Plus exactement, ce problème s’est posé presque de lui-même pendant ma présentation aux Journées Perl 2009, suite à une question du public.

En fait, je n’avais que la moitié de la solution, et depuis, je me suis pris d’un défi pour résoudre correctement ce problème avec Coat::Persistent.

Je vous propose de voir ensemble comment faire.

Objectifs

• Utiliser le champ date comme un entier dans le code Perl
• Ne pas avoir a se soucier de son format de stockage

Dans sa version actuelle, Coat::Persistent ne fait pas de différence entre la valeur assignée a un attribut d’un objet et celle stockée en base. Il nous est donc impossible de réaliser notre objectif de manière élégante sans modifier Coat::Persistent.

La bonne façon de permettre cette fonctionnalité serait donc de dire qu’un attribut peut avoir un type propre (isa) et un type de stockage. On aurait donc quelquechose comme ça :

has_p created_at => (
    is => 'rw',
    isa => 'Int',
    store_as => 'DateTime',
);

Un attribut ainsi déclaré serait donc conscient que sa valeur mémoire (celle de l’objet instancié) est différente de celle stockée en base. Toute la logique de conversion qu’elle soit dans un sens ou dans l’autre serait donc gérée par Coat::Persistent, et non pas par l’utilisateur.

Tout cela est réalisable en utilisant une coercition bi-directionnelle. Derrière ce mot barbare se cache un principe finalement assez simple : une valeur x doit être convertible d’un type A vers un type B, et reciproquement.

Coat permet de définir des coeriction via le mécanisme de types utilisateurs. La subtilité est donc de :

• Avoir une coercition de définie pour pouvoir convertir une valeur du type de l’attribut vers une valeur du type de stockage (qui interviendra avant un save)
• Avoir une coercition de définie pour pouvoir convertir une valeur du type de stockage vers une valeur du type de l’attribut (qui interviendra après un find)

Voyons maintenant comment écrire ces types et leur règle de coercition respectives pour le coupe Int,DateTime

Nous allons commencer par définir le type DateTime que nous voulons utiliser pour représenter le format de stockage des date dans une table MySQL (YYYY-MM-DD HH:MM:SS).

subtype 'DateTime'
    => as 'Str'
    => where { /^\d\d\d\d-\d\d-\d\d \d\d:\d\d:\d\d$/ };

Un attribut de type DateTime est donc un attribut de type Str et dont la valeur respecte la regexp fournie.
Maintenant il nous faut écire la règle de conversion d’une valeur Int vers une valeur DateTime :

coerce 'DateTime'
    => from 'Int'
    => via {
        my ($sec, $min, $hour, $day, $mon, $year) =
            localtime($_);
        $year += 1900;
        $mon++;
        $day = sprintf('%02d', $day);
        $mon = sprintf('%02d', $mon);
        $hour = sprintf('%02d', $hour);
        $min = sprintf('%02d', $min);
        $sec = sprintf('%02d', $sec);
        return "$year-$mon-$day $hour:$min:$sec";
    };

Le type Int est un type standard, nous n’avons donc pas besoin de le définir. Nous avons seulement besoin de mettre en place une coercition depuis le type DateTime vers le type Int :

coerce 'Int'
    => from 'DateTime'
    => via {
        my ($year, $mon, $day, $hour, $min, $sec) =
             /^(\d{4})-(\d\d)-(\d\d) (\d\d):(\d\d):(\d\d)$/;
        $year -= 1900;
        $mon--;
        return mktime(
            int($sec), int($min), int($hour),
            $day, $mon, $year);
    };

Bien, tout ce code est intéressant, mais est-ce réellement à l’utilisateur de l’ORM de le définir ? Je ne crois pas, sa place serait idéale dans un jeu de types prédéfinis.

Pourquoi pas proposer une module Coat::Persistent::Types avec tous les types nécessaires ? Cela me semble bien plus élégant.

Imaginons donc que les types et coercitions définis ci-dessus seraient présents dans, Coat::Persistent::Types::MySQL. Le type pourrait même se nommer 'MySQL:DateTime' au lieu de 'DateTime'.

L’utilisateur pourrait donc faire tout simplement :

package Stuff;
use Coat;
use Coat::Persistent;
use Coat::Persistent::Types::MySQL;

has_p created_at => (
    isa => 'Int',
    store_as => 'MySQL:DateTime',
);

Et le tour serait joué !

Il ne resterait alors qu’une seule chose à faire : patcher la mécanique de sauvegarde de Coat::Persistent pour que les valeurs utilisées dans le SQL puissent être converties si nécessaire.

Cela peut se faire très simplement en introduisant la notion de valeur de stockage. Cette valeur serait égale à celle de l’attribut si aucun store_as n’est défini, elle serait égale à la coercition adéquate sinon.

Bien, maintenant que ce problème est résolu, il ne me reste plus qu’à patcher Coat::Persistent et à publier une nouvelle version avec toutes ces bonnes calories intellectuelles…

Related posts:

1. Publication de Coat::Persistent 0.200 Je viens d’uploader Coat::Persistent sur CPAN. Voila une bonne chose...
2. Coat Persistent La famille de Coat s’agrandit, voici un premier essai de...
3. Nouvelle fonctionnalité pour Coat::Persistent : cache Une nouvelle fonctionnalité va faire son apparition d’ici peu de...

A noter au passage que d’après ce que m’a dit Sébastien Déseille – vice-président des Mongueurs et organisateur de l’événement – ces salles sont grâcieusement prétées à l’association, ce qui a permi de rendre cette conférence entièrement gratuite. Une belle initiative qui méritait d’être salluée.

J’ai d’abord assisté à la présentation de Philippe « BooK » Bruhat sur les opérateurs secrets de Perl : il s’agit d’un cocktail explosif de Perl, d’ASCII Art, de Star Wars et d’humour – avec un zeste de Goatse.

Finalement, BooK nous a montré comment on peut combiner différents opérateurs entre eux et avec les jeux de précédence, obtenir de nouveaux opérateurs, ou même des constantes.

L’immagination semble être la seule limite à cette véritable chasse au trésor. Quelques exemples pris sur le vif :

• Bang Bang : !! $anyvalue : retourne l’expression booléenne de $anyvalue
• Inch Worm : ~~ @anylist : retourne l’expression scalaire de @anylist
• Goatse : $count =()= $regexp : Retounre le nombre de match dans la $regexp sur $_

Je vous renvoie aux slides de BooK Pour plus de détails (et surtout pour les illustrations croustillantes).

Après la pause déjeuner, c’était au tour de Coat d’être présenté par SébastienDéseille.

Pour sa présentation, Sébastien s’est donné comme défi de reprendre la série d’articles publiée sur ce blog et dédiée à l’apprentissage de Moose afin de l’adapter avec Coat. On a ainsi pu découvrir comment faire de l’objet avec Coat et avoir les bases nécessaires à l’apprentissage de Coat::Persistent.

J’ai donc ensuite présenté le petit frère Coat::Persistent dont voici les slides :

La vidéo de la présentation sera probablement en ligne prochainement, certainement par ici.

Dans l’ensemble la présentation s’est bien déroulée (du moins je l’espère :-).

J’aurais juste dû choisir un autre exemple pour la coercition car le mien ne correspondait pas à quelquechose de convenable en pratique. Lorsqu’on s’en rend compte en pleine présentation suite à une question du public ce n’est pas très agréable.

Du côté des bonnes surprises, Philippe Bruhat m’a parlé de son module Test::Database qui m’à tout l’air d’être le module manquant du jeu de test de Coat::Persistent : il permet de d’obtenir un pool de $dbh disponibles sur la machine courante, pour une série de drivers. C’est tout simplement l’outil révé pour écrire le jeu de tests unitaires de Coat::Persistent (pour l’instant je suis contraint à faire tourner les tests uniquement avec le driver CSV). A suivre donc.

Related posts:

1. Coat Persistent La famille de Coat s’agrandit, voici un premier essai de...
2. Publication de Coat::Persistent 0.200 Je viens d’uploader Coat::Persistent sur CPAN. Voila une bonne chose...
3. Nouvelle fonctionnalité pour Coat::Persistent : cache Une nouvelle fonctionnalité va faire son apparition d’ici peu de...

Du coup, j’en ai profité pour modifier subtilement la gestion des drivers DBI. En effet, comme me l’avait fait remarquer Sébastien Déseille dans un échange de mails (Sébastien présentera le module Coat), uniquement les drivers MySQL et CSV étaient supportés alors qu’un simple patch d’une ligne permettait de faire fonctionner C::P avec SQLite.

Il est vrai qu’intrinsèquement, rien n’interdit d’autres drivers : le SQL généré est standard puisque produit par SQL::Abstract, et les séquences sont gérées par DBIx::Sequence et ne reposent donc pas sur le SGBD.

La seule difficulté était donc de maintenir une liste de drivers de la bonne façon. J’ai opté pour un compromis :

• D’une part, plutôt que de lister en dur dans le code de C::P la liste de tous les drivers DBI potentiellement compatibles, j’ai préféré ne lister par défaut que ceux pour lesquels je sais que tout fonctionne bien
• D’autre part, le module propose une interface pour laisser le programme appelant modifier ce registre de drivers, il peut ainsi – sans patcher C::P – modifier ou ajouter les drivers connus

La documentation a été mise à jour et montre l’usage des nouvelles méthodes drivers(), get_driver() et add_driver().

Related posts:

1. Nouvelle version de Coat : 0.333 disponible sur le CPAN J’ai publié une nouvelle version de Coat – la meta-classe...
2. Nouvelle fonctionnalité pour Coat::Persistent : cache Une nouvelle fonctionnalité va faire son apparition d’ici peu de...
3. Coat::Persistent aux Journées Perl 2009 Je reviens à l’instant des Journées Perl 2009. La conférence...