Base de données

Une discussion solide sur le design du modèle de données de Elgg et ses motivations.

Aperçu

Dans Elgg, tout fonctionne sur un modèle de données unifié construit sur des unités atomiques de données appelées entités.

Il est recommandé que les plugins n’interagissent pas directement avec la base de données, afin de créer un système plus stable et une meilleure expérience utilisateur parce que les contenus créés par différents plugins peuvent être mélangés ensemble de manière cohérente. Avec cette approche, les plugins sont plus rapides à développer, et sont en même temps plus puissants.

Chaque entité dans le système hérite de la classe ElggEntity. Cette classe contrôle les permissions d’accès, la propriété, le conteneur, et fournit une API cohérente pour accéder aux propriétés des entités et les modifier.

Vous pouvez étendre les entités avec des informations supplémentaires de deux manières :

Metadata : Ces informations décrivent l’entité, elles sont habituellement

ajoutées par l’auteur de l’entité quand l’entité est créée ou modifiée. Des exemples de métadonnées incluent les tags, un numéro ISBN ou un ID tierce-partie, une adresse, des coordonnées géographiques, etc. Imaginez les métadonnées comme un simple système de stockage clef-valeur.

Annotations : Ces informations étendent l’entité avec des propriétés, habituellement

ajoutées par une tierce-partie. De telles propriétés comprennent par exemple les notations, les likes ou les votes.

Les principales différences entre métadonnées et annotations :

• les métadonnées n’ont pas de propriétaire, alors que les annotations en ont

• les métadonnées ne disposent pas de contrôle d’accès, alors que les annotations en disposent

• les métadonnées sont préchargées lorsque l’entité est construite, alors que les annotations ne sont chargées que sur demande

Ces différences peuvent avoir des implications sur les performances et votre logique applicative, aussi considérez avec soin la manière dont vous souhaiter attacher des données à vos entités.

Dans certains cas, il peut être préférable d’éviter d’utiliser des métadonnées et annotations, et de créer de nouvelles entités à la place, puis de les attacher via container_guid ou une relation.

Modèle de données

Le diagramme du modèle de données de Elgg

Entités

ElggEntity est la classe de base pour le modèle de données de Elgg et supporte un jeu de propriétés et de méthodes communes.

• Un identifiant global unique (Globally Unique IDentifier - Voir GUIDs)

• Permissions d’accès . (Quand un plugin demande des données, il n’accède jamais à des données que l’utilisateur courant n’a pas la permission de voir)

• Un sous-type arbitraire (plus d’informations ci-dessous)

• Un propriétaire

• Un conteneur, utilisé pour associer le contenu avec un groupe ou un utilisateur

• Timestamps UNIX pour certaines actions :

  • Quand l’entité a été créée

  • Quand l’entité a été modifiée pour la dernière fois

  • Quand l’entité a-t-elle effectué sa dernière action ou a-t-elle été sollicitée ?

  • Quand l’entité a été supprimée

• Un état supprimé (les entités supprimées ne sont pas affichées dans des circonstances normales)

• Un état désactivé (les entités désactivées ne sont pas affichées dans des circonstances normales)

Types

Les entités réelles seront des instances de quatre sous-classes différentes, chacune ayant une propriété type distincte et ses propres propriétés et méthodes supplémentaires.

Type	Classe PHP	Représente
object	ElggObject	Les plupart des contenus créés par les utilisateurs, tels que des articles de blog, des chargements de fichiers, et des signets.
group	ElggGroup	Un groupe organisé d’utilisateurs avec sa propre page de profil
user	ElggUser	Un utilisateur du système
site	ElggSite	Le site servi par l’installation Elgg

Chaque type a sa propre API étendue. Par ex. les utilisateurs peuvent être en contact avec d’autres utilisateurs, un groupe peut avoir des membres, tandis que les objets peuvent être aimés et commentés.

Sous-types « subtypes »

Chaque entité doit définir un sous-type subtype, que les plugins utilisent pour spécialiser encore l’entité. Elgg facilite le fait de rechercher des entités spécifiques d’un sous-type donné (ou de plusieurs), ainsi que de leur assigner des comportements et vues spéciales.

Les sous-types sont communément donnés aux instances de ElggEntity pour définir le type de contenu créé. Par ex. le plugin blog crée des objets avec le sous-type "blog".

Par défaut, les utilisateurs, les groupes et les sites ont respectivement les sous-types user, group et site.

Les plugins peuvent utiliser des classes d’entités personnalisées qui étendent la classe de base du type. Pour cela, ils doivent enregistrer leur classe au démarrage (par ex. dans le gestionnaire 'init', 'system'), en utilisant elgg_set_entity_class(). Par exemple, le plugin blog pourrait utiliser elgg_set_entity_class('object', 'blog', \ElggBlog::class).

Les plugins peuvent utiliser elgg-plugin.php pour définir une classe d’entité via le paramètre raccourci entities.

Trucs à savoir sur les sous-types

Avant que la méthode save() d’une entité soit appelée, le sous-type doit être défini en écrivant une chaîne de caractère dans la propriété subtype.

Avertissement

Le sous-type ne peut pas être changé après l’enregistrement.

GUIDs

Un GUID est un entier qui définit de manière unique chaque entité dans une installation Elgg (un IDentifiant Global Unique - Globally Unique IDentifier). Il est assigné automatiquement la première fois qu’une entité est enregistré, et ne peut jamais être changé.

Certaines fonctions de l’API de Elgg fonctionnent avec des GUIDs au lieu d’objets ElggEntity.

État supprimé

Depuis Elgg 6.0, les entités ont également un état supprimé. Lorsqu’un type/sous-type d’entité le prend en charge avant d’être supprimé de la base de données, il peut obtenir cet état. Ainsi, un utilisateur peut restaurer l’entité si la suppression a été effectuée trop rapidement. Par exemple, un utilisateur supprime un article de blog, alors qu’il n’aurait pas dû le faire. Il a désormais la possibilité de restaurer le blog dans son état d’origine sans avoir à le réécrire.

Dans la base de données, ceci est géré par la colonne deleted dans la table entities qui peut avoir une valeur de yes ou no (par défaut) et par la colonne time_deleted qui contient un horodatage UNIX de la suppression de l’entité.

L’administrateur du site peut définir une période de conservation pour les éléments supprimés. Une fois cette période écoulée, l’entité sera définitivement supprimée de la base de données.

Les éléments supprimés ne s’afficheront pas dans les cas d’utilisation normaux. Dans l’exemple de l’article de blog, le blog n’apparaîtra pas dans la liste du blog, et si quelqu’un a enregistré un lien vers l’article de blog, la page renverra une erreur 404 - Not Found.

Une page spéciale dans les paramètres de l’utilisateur permet de consulter toutes les entités supprimées. L’utilisateur peut alors choisir de restaurer l’entité ou de la supprimer définitivement avant la fin de la période de conservation.

Cette page spéciale est également disponible pour les propriétaires de groupe pour les entités supprimées dans leur groupe.

Voir aussi

Pour plus d’information veuillez consulter la Capacité de restauration documentation

ElggObject

Le type d’entité ElggObject représente un type de contenu arbitraire au sein d’une installation Elgg, tel que des articles de blog, des fichiers, etc.

Au-delà des propriétés standards de ElggEntity, ElggObject supporte également :

• title Le titre de l’objet (texte sans HTML)

• description Une description de l’objet (HTML)

La plupart des autrse données à propos de l’objet sont généralement stockées via des métadonnées.

Note

Il est recommandé d’enregistrer une extension personnalisée d’un ElggObject pour votre sous-type (par exemple blog, file, etc.). Vous pouvez ainsi définir le sous-type comme étant toujours le vôtre, configurer les champs de formulaire par défaut si nécessaire et créer facilement une autre fonction d’aide.

ElggUser

Le type d’entité ElggUser représente les utilisateurs au sein d’une installation Elgg. Ils seront définis comme désactivés jusqu’à-ce que leur compte ait été activé (à moins qu’ils n’aient été créés à partir du panneau d’administration).

Au-delà des propriétés standards de ElggEntity, ElggUser supporte également :

• name Le nom de l’utilisateur en texte brut. Par ex. « Hugh Jackman »

• username Leur identifiant. Par ex. « hjackman »

• password Une version hachée de leur mot de passe

• email Leur adresse e-mail

• language Leur code de langue par défaut.

• prev_last_action La précédente valeur de last_action

• last_login Le timestamp UNIX de leur dernière connexion

• prev_last_login la précédente valeur de last_login

ElggSite

Le type d’entité ElggSite représente votre installation Elgg (via l’URL de votre site).

Au-delà des propriétés standards de ElggEntity, ElggSite supporte également :

• name Le nom du site

• description Une description du site

• url L’adresse du site

ElggGroup

Le type d’entité ElggGroup représente une association d’utilisateurs Elgg. Les utilisateurs peuvent rejoindre, quitter les groupes, et y publier du contenu.

Au-delà des propriétés standards de ElggEntity, ElggGroup supporte également :

• name Le nom du groupe (texte sans HTML)

• description Une description du groupe (HTML)

ElggGroup a des méthodes additionnelles pour gérer le contenu et les adhésions.

Le plugin Groups

A ne pas confondre avec le type d’entité ElggGroup, Elgg vient avec un plugin appelé « Groups » qui fournit une UI/UX par défaut pour que les utilisateurs du site interagissent avec les groupes. Chaque groupe dispose d’une page d’accueil qui relie les utilisateurs au contenu du groupe..

Vous pouvez modifier l’expérience utilisateur via les moyens traditionnels d’extension de plugin, ou remplacer complètement le plugin Groups par votre propre plugin.

Plusieurs des plugins principaux d’Elgg offrent une prise en charge du contenu de groupe comme les blogs, les signets, les discussions, les fichiers et les pages.

Écrire un plugin compatibles avec les groupes

Les développeurs de plugins ne devraient pas trop s’inquiéter de l’écriture de fonctionnalités compatibles avec les groupes, mais il y a quelques points clefs :

Ajouter du contenu

En passant le groupe en tant que container_guid via un champ de saisie caché, vous pouvez utiliser un seul formulaire et une seule action pour ajouter du contenu à la fois pour un utilisateur ou pour un groupe.

Utilisez ElggEntity->canWriteToContainer(0, $type, $subtype) pour déterminer si l’utilisateur actuel a le droit d’ajouter du contenu à un groupe.

Soyez attentif au fait que vous allez devoir passer le GUID du conteneur ou l’identifiant à la page responsable de la publication, et la valeur associée, de sorte que ceci puisse être ensuite conservé dans votre formulaire sous forme de champ de saisie caché, pour un passage plus aisé vers vos actions. Au sein d’une action « create », vous allez avoir besoin de récupérer ce champ de saisie et de l’enregistrer sous forme de propriété de votre nouvel élément (la valeur par défaut est le conteneur actuel de l’utilisateur) :

$user = elgg_get_logged_in_user_entity();
$container_guid = (int) get_input('container_guid');

if ($container_guid) {
    $container = get_entity($container_guid);

    if (!$container instanceof \ElggEntity || !$container->canWriteToContainer($user->guid, 'object', 'my_content_subtype')) {
        return elgg_error_response(elgg_echo('actionunauthorized'));
    }
} else {
    $container_guid = elgg_get_logged_in_user_guid();
}

$object = new YourObjectClass();
$object->container_guid = $container_guid;

...

// redirect to the created object
return elgg_ok_response('', $object->getURL());

Propriété

Les entités ont une propriété GUID owner_guid, qui définit son propriétaire. Typiquement ceci renvoie au GUID d’un utilisateur, quoique les sites et les utilisateurs eux-même n’ont souvent pas de propriétaire (valeur de 0).

La propriété d’une entité détermine, d’une part, si vous pouvez ou non accéder à cette entité, ou la modifier.

Conteneurs « containers »

Afin de rechercher aisément du contenu par groupe ou utilisateur, le contenu est généralement défini comme « contenu » soit par l’utilisateur qui l’a publié, soit par le groupe dans lequel l’utilisateur l’a publié. Ceci signifie que la propriété container_guid des nouveaux objets sera définie avec la valeur du ElggUser actuel ou du ElggGroup cible.

Par ex., trois articles de blog peuvent avoir des propriétaires différentes, mais être tous contenus dans le groupe où ils ont été publiés.

Note

Note : Ceci n’est pas toujours vrai. Les entités des commentaires sont contenues par l’objet commenté, et dans certains plugins tierce-partie le conteneur peut être utilisé pour modéliser des relations parents-enfants entre entités (par ex. un objet dossier « folder » qui contient un objet de type fichier).

Annotations

Les annotations sont des éléments de données attachées à une entité qui permet aux utilisateurs de laisser des évaluations, ou d’autres types de réactions pertinentes. Un plugin de sondage pourrait enregistrer des votes sous forme d’annotations.

Les annotations sont stockées sous formes d’instances de la classe ElggAnnotation.

Chaque annotation dispose de :

• Un type d’annotation interne (tel que comment)

• Une valeur (qui peut être une chaîne de caractères, un booléen ou un entier)

• Un niveau d’accès distinct de celui de l’entité à laquelle elle est attachée

• Un propriétaire

Ajouter une annotation

La manière la plus simple d’ajouter une annotation est d’utiliser la méthode annotate sur une entité, qui est définie comme :

public function annotate(
    $name,           // The name of the annotation type (eg 'comment')
    $value,          // The value of the annotation
    $access_id = 0,  // The access level of the annotation
    $owner_id = 0,   // The annotation owner, defaults to current user
    $vartype = ""    // 'text', 'bool' or 'integer'
)

Par exemple, pour donner une notation à une entité, vous pouvez appeler :

$entity->annotate('rating', $rating_value, $entity->access_id);

Lire des annotations

Pour récupérer les annotations d’une entité, vous pouvez appeler la méthode suivante :

$annotations = $entity->getAnnotations(
    $name,    // The type of annotation
    $limit,   // The number to return
    $offset,  // Any indexing offset
    $order,   // 'asc' or 'desc' (default 'asc')
);

Si votre type d’annotation utilise largement des valeurs entières, plusieurs fonctions mathématiques utiles sont fournies :

$averagevalue = $entity->getAnnotationsAvg($name);  // Get the average value
$total = $entity->getAnnotationsSum($name);         // Get the total value
$minvalue = $entity->getAnnotationsMin($name);      // Get the minimum value
$maxvalue = $entity->getAnnotationsMax($name);      // Get the maximum value

Fonctions d’assistance utiles

Commentaires

Si vous souhaitez fournir une fonctionnalité de commentaire sur les objets de votre plugin, la fonction suivante va fournir le listing complet, le formulaire et les actions :

function elgg_view_comments(ElggEntity $entity)

Métadonnées

Les métadonnées dans Elgg vous permettent de stocker les données supplémentaires d’une ElggEntity au-delà des champs prédéfinis que cette entité supporte. Par exemple, ElggObjects ne supporte que les champs d’entités basiques plus un titre et une description, mais vous pouvez souhaiter inclure également des tags ou un numéro ISBN. De manière similaire, vous pourriez souhaiter que les utilisateurs puissent enregistrer une date de naissance.

Sous le capot, les métadonnées sont stockées sous forme d’instance de la classe ElggMetadata, mais vous n’avez pas à vous soucier de cela en pratique (quoique si vous êtes intéressé, voyez la référence de la classe ElggMetadata). Ce que vous avez besoin de savoir :

• Vous pouvez potentiellement avoir plusieurs éléments de chaque type de métadonnée attachés à la même entité

• Comme les annotations, les valeurs sont stockées sous forme de chaînes de caractères, de booléens ou d’entiers

• Le nom de la métadonnée est sensible à la casse

Le cas simple

Ajouter des métadonnées

Pour ajouter une métadonnée à une entité, appelez simplement :

$entity->metadata_name = $metadata_value;

Par exemple, pour ajouter une date d’anniversaire à un utilisateur :

$user->dob = $dob_timestamp;

Ou pour ajouter des tags à un objet :

$object->tags = array('tag one', 'tag two', 'tag three');

Lorsque vous ajoutez une métadonnée de cette manière :

• Réassigner une métadonnée va remplacer l’ancienne valeur

Ceci convient pour la plupart des objectifs. Faites attention à bien noter quels attributs sont des métadonnées et lesquels sont natifs au type d’entité avec lequel vous travaillez. Vous n’avez pas besoin d’enregistrer une entité après avoir ajouté ou modifié des métadonnées. Vous devez enregistrer une entité si vous avez changé l’un des ses attributs natifs. A titre d’exemple, si vous avez changé l”access_id d’un ElggObject, vous devez l’enregistrer, faute de quoi la modification ne sera pas conservée dans la base de données.

Lire des métadonnées

Pour récupérer une métadonnée, traitez-la comme une propriété d’une entité :

$tags_value = $object->tags;

Notez que ceci va retourner la valeur absolue de la métadonnée. Pour récupérer des métadonnées sous forme d’objet ElggMetadata, vous devrez utiliser les méthodes décrites dans la section contrôle plus fin ci-dessous.

Si vous stockez de multiples valeurs dans cette métadonnée (comme dans l’exemple « tags » ci-dessus), vous obtiendrez un tableau de toutes ces valeurs. Si vous stockez seulement une valeur, vous récupérerez une chaîne de caractères, un booléen ou un entier. Stocker un tableau avec seulement une valeur vous retournera une chaîne de caractères. Par ex.

$object->tags = array('tag');
$tags = $object->tags;
// $tags will be the string "tag", NOT array('tag')

Pour récupérer toujours un tableau, castez simplement vers un tableau ;

$tags = (array)$object->tags;

Lire des métadonnées comme des objets

elgg_get_metadata est la meilleure fonction pour récupérer les métadonnées sous forme d’objets ElggMetadata :

Par ex., pour récupérer la date de naissance d’un utilisateur

elgg_get_metadata([
    'metadata_name' => 'dob',
    'guid' => $user_guid,
]);

Ou pour récupérer tous les objets de métadonnées :

elgg_get_metadata([
    'guid' => $user_guid,
    'limit' => false,
]);

Note

Lors de la récupération des métadonnées par nom, les noms sont mis en correspondance sans distinction de casse. Veillez à la propreté de votre code et évitez de mélanger les majuscules et les minuscules dans les noms de métadonnées.

Erreurs courantes

« Ajouter » des métadonnées à la suite

Notez que vous ne pouvez pas « ajouter » des valeurs aux tableaux de métadonnées comme si c’étaient des tableaux php normaux. Par exemple, le code suivant ne fera pas ce qu’il semblerait qu’il devrait faire.

$object->tags[] = "tag four";

Essayer de stocker des tableaux indexés

Elgg ne supporte pas le stockage de tableaux indexés (paires clef/valeur) dans les métadonnées. Par exemple, le code suivant ne fonctionne pas comme vous pourriez le penser de prime abord :

// Won't work!! Only the array values are stored
$object->tags = array('one' => 'a', 'two' => 'b', 'three' => 'c');

Au lieu de cela, vous pouvez conserver cette information de cette manière :

$object->one = 'a';
$object->two = 'b';
$object->three = 'c';

Conserver des GUIDs dans des métadonnées

Quoiqu’il existe certains cas pour stocker les GUIDs d’entités dans des métadonnées, les relations Relationships sont une construction bien plus adaptée pour relier les entités les unes aux autres.

Relations

Les relations vous permettent d’associer des entités ensemble. Exemples : un artiste a des fans, un utilisateur est membre d’une organisation, etc.

La classe ElggRelationship modélise une relation directe entre deux entités, en faisant la déclaration :

« {sujet} est un {nom} de {cible}. »

Nom de l’API	Modèles	Représente
guid_one	Le sujet	Quelle entité est reliée
relationship	Le nom	Le type de relation
guid_two	La cible	L’entité à laquelle le sujet est relié

Le type de relation peut également être un verbe, faisant la déclaration :

« {sujet} {verbe} {cible}. »

Par ex. Utilisateur A aime « likes » l’article de blog B

Chaque relation a une direction. Imaginez un archer qui tire une flèche vers une cible ; la flèche se déplace dans une direction, en reliant le sujet (l’archer) à la cible.

Une relation n’implique pas de réciprocité. A suit B n’implique pas que B suive A.

Les relations n’ont pas de contrôle d’accès. Elles ne sont jamais cachées d’une vue et peuvent être modifiées par le code avec n’importe quel niveau de privilège, par contre les entités d’une relation peuvent être invisible en raison du contrôle d’accès !

Travailler avec les relations

Créer une relation

Par exemple pour établir que l’utilisateur « $user est un fan de l’artiste $artist » (l’utilisateur est le sujet, l’artiste est la cible):

$success = $user->addRelationship($artist->guid, 'fan');

Ceci déclenche l’événement [create, relationship], en lui passant l’objet ElggRelationship créé. Si un gestionnaire retourne false, la relation ne sera pas créée et $success vaudra false.

Vérifier une relation

Par exemple pour vérifier que l’utilisateur « $user est un fan de l’artiste $artist »:

if ($user->hasRelationship($artist->guid, 'fan')) {
    // relationship exists
}

Supprimer une relation

Par exemple pour pouvoir affirmer que l’utilisateur « $user n’est désormais plus un fan de l’artiste $artist »:

$was_removed = $user->removeRelationship($artist->guid, 'fan');

Ceci déclenche l’événement [delete, relationship], en lui passant l’objet ElggRelationship associé. Si un gestionnaire retourne false, la relation sera conservée, et $was_removed vaudra false.

Autres fonctions utiles :

• \ElggRelationship->delete(): supprime par objet

• \ElggEntity->removeAllRelationships(): supprime toutes les relations associées à une entité

Trouver des relations et des entités associées

Vous trouverez ci-dessous quelques fonctions permettant de récupérer des objets relationnels et/ou des entités associées :

• elgg_get_relationship() : récupère un objet relationship par son ID

• elgg_get_relationships() : récupère des relations

• elgg_get_entities() : récupère les entités dans les relations de différentes manières

Par ex. retrouver les utilisateurs qui ont rejoint votre groupe en janvier 2014.

$entities = elgg_get_entities(array(
    'relationship' => 'member',
    'relationship_guid' => $group->guid,
    'inverse_relationship' => true,

    'relationship_created_after' => 1388534400, // January 1st 2014
    'relationship_created_before' => 1391212800, // February 1st 2014
));

Contrôle d’accès

Les contrôle d’accès granulaires sont l’un des principes de design fondamentaux dans Elgg, et une fonctionnalité qui a été au cœur du système tout au long de son développement. L’idée est simple : un utilisateur devrait avoir un contrôle total sur qui peut voir un élément de donnée qu’il ou elle a créé.

Niveau d’accès dans le modèle de données

Pour parvenir à cela, chaque entité et annotation contient une propriété access_id, qui correspond à l’un des niveau d’accès prédéfinis ou à une entrée dans la table access_collections de la base de données.

Niveaux d’accès prédéfinis

• ACCESS_PRIVATE (valeur : 0) Privé.

• ACCESS_LOGGED_IN (valeur : 1) Utilisateurs connectés.

• ACCESS_PUBLIC (valeur : 2) Données publiques.

Niveaux d’accès définis par l’utilisateur

Vous pouvez définir des groupes d’accès additionnels et les assigner à une entité, ou une annotation. Un certain nombre de fonctions ont été définies pour vous y aider ; voyez Listes de Contrôle d’Accès pour plus d’informations.

Comment les accès affectent la récupération de données

Toutes les récupérations de données fonctionnent au-dessus de la couche de la base de données - par exemple elgg_get_entities ne retournera que les éléments que l’utilisateur actuel a l’autorisation de voir. Il n’est pas possible de récupérer des éléments auxquels l’utilisateur actuel n’a pas accès. Ceci rend très difficile de créer un trou de sécurité pour récupérer des données.

Accès en écriture

Les règles suivantes gouvernent les accès en écriture :

• Le propriétaire d’une entité peut toujours la modifier

• Le propriétaire d’un conteneur peut modifier tout ce qui est dedans (notez que cela ne signifie pas que le propriétaire d’un groupe peut modifier toutes les publications dans ce groupe)

• Les administrateurs peuvent tout éditer

Vous pouvez remplacer ce comportement en utilisant un event appelé permissions_check, qui transmet l’entité en question à toute fonction ayant annoncé qu’elle souhaite être référencée. Renvoyer true autorisera l’accès en écriture ; renvoyer false le bloquera. Voir le guide de référence des événement pour la vérification des permissions pour plus de détails.

Schéma

La base de données contient un certain nombre de tables primaires et secondaires. Vous pouvez suivre les évolutions du schéma dans engine/schema/migrations/

L’ensemble de caractères de la base de données doit être utf8mb4, ce qui fournira une prise en charge complète des caractères unicode lors du stockage des données.

InnoDB

À partir de Elgg 3.0, la base de données utilise le moteur InnoDB. Pour une installation ou une migration correcte, certains paramètres peuvent devoir être ajustés dans les paramètres de la base de données.

• innodb_large_prefix devrait être on

• innodb_file_format devrait être Barracuda

• innodb_file_per_table devrait être 1

Tables principales

Voici la description des principales tables. Gardez à l’esprit que pour une installation de Elgg donnée, les tables vont avoir un préfixe (typiquement « elgg_ »).

Table : entities - entités

Ceci est la table principale Entities qui contient les utilisateurs, sites, objets et groupes Elgg. Quand vous installez Elgg la première fois elle est automatiquement remplie avec votre premier site, votre premier utilisateur, et un jeu de plugins intégré.

Elle contient les champs suivants :

• guid Un compteur auto-incrémenté qui produit un GUID qui identifie de manière unique cette entité dans le système

• type Le type d’entity - object, user, group ou site

• subtype Le sous-type d’entité

• owner_guid Le GUID de l’entité du propriétaire

• container_guid Le GUID dans laquelle cette entité est contenue - soit un utilisateur « user » soit un groupe « group »

• access_id Contrôles d’accès sur cette entité

• time_created Le timestamp Unix de création de l’entité

• time_updated Le timestamp Unix de la dernière modification de l’entité

• last_action Horodatage Unix du moment où l’utilisateur a effectué une dernière action ou du moment où quelque chose s’est produit dans l’entité en tant que conteneur

• enabled Si “yes” -oui- l’entité est accessible, si “no” -non- l’entité a été désactivée (Elgg traite cela comme si elle avait été supprimée sans toutefois la supprimer réellement de la base de données)

• deleted Si la valeur est “oui”, l’entité est marquée comme supprimée. Si la valeur est “no” (par défaut), l’entité est visible sur un site standard. Les entités supprimées peuvent être consultées dans la corbeille.

• time_deleted Le timestamp Unix de la date de suppression de l’entité

Table : metadata

Cette table contient des métadonnées Metadata, des informations supplémentaires attachées à une entité.

• id Un IDentifiant unique

• entity_guid L’entité à laquelle cette métadonnée est attachée

• name Le nom de la chaîne

• value La valeur de la chaîne

• value_type La classe de la valeur, soit une chaîne de caractères, un booléen ou un entier

• time_created Le timestamp Unix de la date de création de la métadonnée

Table : annotations

Cette table contient les Annotations, ce qui est distinct des Metadata.

• id Un IDentifiant unique

• entity_guid L’entité à laquelle cette métadonnée est attachée

• name Le nom de la chaîne

• value La valeur de la chaîne

• value_type La classe de la valeur, soit une chaîne de caractères, un booléen ou un entier

• owner_guid Le GUID du propriétaire qui a défini cette annotation

• access_id Un Contrôle d’Accès sur cette annotation

• time_created Le timestamp Unix de la date de création de l’annotation.

Table : relationships - relations

Cette table définit les relations Relationships, qui relient une entité avec une autre.

• guid_one Le GUID de l’entité sujet.

• relationship Le type de relation.

• guid_two Le GUID de l’entité cible.

• time_created Le timestamp Unix de la date de création de la relation.

Tables secondaires

Table : access_collections

Cette table définit les Collections d’Accès, qui donnent accès aux utilisateurs aux Entités ou aux Annotations.

• id Un IDentifiant unique

• *name Le nom de la collection d’accès

• owner_guid Le GUID de l’entité propriétaire (par ex. un utilisateur ou un groupe)

• subtype le sous-type de la collection d’accès (par ex. friends ou group_acl)