Licence CC BY

Des emojis en SQL ? C'est possible… et on peut aller au-delà !

Du code expressif et parfaitement inutilisable

Publié :
Auteur :
Catégories :
Temps de lecture estimé : 3 minutes
Le saviez-vous ?

On peut utiliser des emojis en SQL, et pas seulement pour les manipuler : les emojis peuvent servir d’identifieurs !

Avec PostgreSQL, peut donc faire des choses comme :

CREATE TABLE 👤(
    🔑 INTEGER PRIMARY KEY,
    🗣 varchar(64), -- name
    🗓 DATE -- date of registration
);

Voire carrément :

CREATE TYPEAS ENUM ('🤢', '☹', '😐', '🙂', '😍');

-- [...]

-- select the most common rating for each book
-- MODE() is another function exclusive to PostgreSQL
--- https://wiki.postgresql.org/wiki/Aggregate_Mode
SELECT 📕.💬, MODE() WITHIN GROUP (ORDER BY 👤🏠📕.⭐) AS MostCommonRating
FROM 👤🏠📕 JOIN 📕 ON 👤🏠📕.📕 = 📕.🔑
GROUP BY  📕.🔑;
             💬            | mostcommonrating
---------------------------+------------------
 Alice in Wonderland       | NULL
 Moby Dick                 | NULL
 Through the Looking-Glass | 🙂
 Example Book              | 😍

Je vous renvoie vers cet article pour les détails, et part du principe que vous l’avez lu dans la suite.

Mais on peut faire mieux !

JPA avec Hibernate permet de gérer nativement ces syntaxes… à condition d’utiliser Kotlin, qui permet d’utiliser les emojis en identifiants.

Le code ci-dessous est donc tout à fait valable, compile et démarre :

package fr.spacefox.sqlmoji.model

import javax.persistence.*

@Entity
@Table
data class `✍` (
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        val `🔑`: Int,

        @Column(nullable = false, length = 64) val `🗣`: String,

        @OneToMany(mappedBy = "✍") val `📕`: Collection<`📕`>
)

@Entity
@Table
data class `👤` (
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        val `🔑`: Int,

        @Column(nullable = false, length = 64) val `🗣`: String,
        @Column val `🗓`: LocalDate,

        @ManyToMany
        @JoinTable(
                name = "👤🏠📕",
                joinColumns = arrayOf(JoinColumn(name = "👤" , referencedColumnName = "🔑")),
                inverseJoinColumns = arrayOf(JoinColumn(name = "📕", referencedColumnName = "🔑")))
        var `📕`: List<`📕`> = mutableListOf()
)

@Entity
@Table
data class `📕` (
        @Id
        @GeneratedValue(strategy = GenerationType.IDENTITY)
        val `🔑`: Int,

        @Column(nullable = false, length = 64) val `💬`: String,  // Title
        @Column(length = 64) val `🔖`: String,  // Genre/Tag

        @ManyToOne val `✍`: `✍`,

        @ManyToMany(mappedBy = "📕")
        var `👤`: List<`👤`> = mutableListOf()
)

La syntaxe bizarre à base d’accents graves autours des emojis1 permet d’utiliser un emoji – ou n’importe quel caractère Unicode qui nécessite plus de 16 bits de représentation – en tant qu’identifiant Kotlin. C’est une spécificité du langage qui n’existe pas à ma connaissance en Java.

Et donc, si couple ça à un serveur SpringBoot, au démarrage ça me génère bien une base de données avec la structure suivante :

create table if not exists "✍"
(
    "🔑" serial not null
        constraint "✍_pkey"
            primary key,
    "🗣" varchar(64) not null
);

create table if not exists "👤"
(
    "🔑" serial not null
        constraint "👤_pkey"
            primary key,
    "🗓" date,
    "🗣" varchar(64) not null
);

create table if not exists "📕"
(
    "🔑" serial not null
        constraint "📕_pkey"
            primary key,
    "💬" varchar(64) not null,
    "🔖" varchar(64),
    "✍_🔑" integer
        constraint fk6bj8134ailsb7wn0rxoxra7t1
            references "✍"
);

create table if not exists "👤🏠📕"
(
    "👤" integer not null
        constraint fktm4c4ip5pvf57bj4fvq9xb4jk
            references "👤",
    "📕" integer not null
        constraint fkqpp0i83yuug00b7rhkbl55m6d
            references "📕"
);
Et… ça s’arrête là

Si JPA et Hibernate gèrent très bien ce genre de fantaisie, c’est à peu près les seules bibliothèques dont c’est le cas. Toute tentative d’utiliser Spring avec des classes au nom aussi exotique se solde par un échec.

Ça vient probablement du fait qu’en interne Java utilise une variante d’UTF-16, et que tout ça implique des caractères que l’on ne peut pas représenter avec un seul bloc de 16 bits.

Et c’est probablement mieux comme ça.


  1. Et qui visiblement ne peut pas s’échapper correctement avec le markdown ZdS.



Icône CC BY Twitter.

1 commentaire

Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte