Jointure sur des bases de données différentes avec WebDev 16: encore une déception !

Dans la cas d’une application multibase, on peut être amené à aggréger des données en provenance de bases différentes. La sélection peut s’opérer en 2 étapes: rapatrier les données de chaques bases puis les aggréger en mémoires. Si l’aggrégation consiste à faire une jointure on préfèrerait que cela se fasse dans la “base”.

En J2EE, le développeur ferait appel à des EJB puis avec un EQL ferait la sélection interbase. Il s’appuirait ainsi sur des mécanismes de chargement paresseux afin limiter l’occupation mémoire en évitant de charger la base en mémoire! Comment webdev adresse-t-il se problème ?

Prenons un cas concrêt de 2 requêtes paramêtrées, chacune mettant en jeu des tables sur des bases de données différentes. Le test SQL de chacune de ces 2 requêtes dans l’IDE se fait sans encombre puisque aucune ne fait pas intervenir l’autre. Créons une 3e requêtes qui fait une produit cartésien sur les 2 premières. Cette 3e requête est elle-même paramêtrée afin d’assurer la jointure. Et bien le test SQL de la 3e requête dans l’IDE se passe parfaitement !

Cela donne l’illusion au développeur de pouvoir utiliser la 3e requêtes comme source pour un tableau. Que nenni ! On a droit à une belle explosion, webdev se plaigant que le fichier (table) correspondant à la 3e requête n’existe pas. Dommage que l’IDE laisse au développeur espérer une opération magique qui n’existe pas !

La solution consiste à remplir le tableau manuellement avec le résultat de l’appel à des requêtes SQL manuelles. Il faut déclarer une source de données pour chacune des requêtes et executer le SQL associé sur chacune d’elle (HExecuteEquêteSQL). Ensuite il faut faire de même avec une nouvelle source de données et un requête SQL faisant un produit cartésien sur les 2 premières sources de données.

Finalement on arrive a nos fin mais au prix d’un effort de programmation non négligeable et une rupture dans les concepts: le médecin doit abandonner le confort de la manipulation d’objet dans l’IDE (requêtes) pour écrire du SQL dans une chaine de caratères non validée par l’IDE. Quel dommage !

Serveur mail personnel incompatible avec AOL et BBOX

English: SMTP transfer model Blue arrows can b...
Image via Wikipedia

Dans mon billet du 7 juin 2011 j’expliquais comment mettre en place un serveur mail sur sa propre machine. Le paramétrage du DNS consistait uniquement à paramétrer un champs MX désignant l’adresse de sa propre machine. Cela permet de recevoir les mails qui nous sont adressés. L’envoie de mail ne faisait l’objet d’aucune configuration DNS.

Cette solution fonctionne bien dans 99% des cas. Dans 1% des cas même si la réception des mail fonctionne, l’envoie pose problème à certains serveurs de messagerie. Il est ainsi impossible d’envoyer des mails à des adresses dans le domaine aol.fr ou bbox.fr. Les serveurs de mails de ces domaines semblent vérifier en effet que l’IP de notre serveur est bien celle d’un serveur de mail de notre nom de domaine en effectuant un reverse DNS sur notre IP. Comme on n’a pas paramétré les DNS inverses pour notre IP, aol et bbox constatent que notre IP est celle d’un autre domaine et refuse de dialoguer avec Postfix, voici leur réponse (adresse mail du destinataire

et IP masquées):

  • bbox:
<xxxxxxxxx@bbox.fr>: host mx.bbox.fr[194.158.122.50] said: 550 5.7.1: Client host
    rejected: Rejected: DU0004 Utilisez le serveur SMTP de votre FAI (in reply
    to RCPT TO command)

Ce zèle (pour éviter le spam) est bien dommageable car il empêche le développement de messagerie personnelle. En faisant cela aol et bbox se comporte comme un censeur devant la boite au lettre de leurs utilisateurs empêchant tout facteur non autorisé à y déposer du courrier. Imaginez que votre boite au lettre physique n’accepte que du courrier en provenance d’un service postale donné alors vous ne pourrez plus recevoir du courrier déposé par la main ou un colis envoyé par livreur… Voilà un bel exemple de bêtise contraire contraire à l’esprit d’internet.

La moralité : bannissons l’usage de aol et bbox comme service de messagerie !

Application Mougeon pour N900

L’arrivé de Free Mobile n’a laissé personne indifférents. Même un collègue peu au fait de la téléphonie, n’ayant pas changé d’abonnement depuis 10 ans, va aller chez Free car il en a assez de payer 7€50 pour un abonnement rechargeable ie communication en sus. Les concurrents aussi ont réagi et Orange le réseau où Free fait du roaming prétend que Free Mobile ne respecte pas vraiment l’accord d’itinérance dans son esprit en faisant passer toutes les communications, ou presque, par Orange.

Pour Android, des applications ont fleuri pour afficher clairement le réseau utilisé (Free ou Orange). Ne voulant pas que le N900 soit en reste, j’ai décidé de faire ma petite application Mougeon. Elle se veut simple car le mougeon à une ascendance de pigeon et n’a pas beaucoup de cervelle, alors bientôt même le mougeon pourra dire s’il est Free ou Orange.