Base de données

Une discussion solide sur le design du modèle de données 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 peut être mélangés ensemble de manières cohérentes. 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é

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

Metadata : Métadonnées. Il s’agit d’une information qui décrit l’entité, généralement

ajoutée par l’auteur de l’entité lorsque l’entité est créée. Par exemple des tags, un numéro ISBN, l’emplacement d’un fichier, ou la langue de la source sont des métadonnées.

Annotations : Il s’agit d’une information à propos de l’entité, généralement

ajoutée par une tierce partie après que l’entité a été créée. Par exemple des notations, des likes, et des votes sont des annotations. (Les commentaires en étaient également avant la 1.9.)

Modèle de données (datamodel)

The Elgg data model diagram

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

Entités

ElggEntity est la classe de base pour le modèle de données d’Elgg et supporte un jeu de propriétés et 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 actuel n’a pas la permission de voir.)

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

  • Un propriétaire (owner).

  • Le site auquel appartient cette entité.

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

Types

Les véritables entités seront des instances de quatre sous-classes différentes, chacune ayant une propriété type distincte et leur propres propriétés et méthodes additionnelles.

Type

Classe PHP

Représente

objet

ElggObject

Les plupart des contenus créés par les utilisateurs, tels que des articles de blog, des chargements de fichiers, et des signets.

groupe

ElggGroup

Un groupe organisé d’utilisateurs avec sa propre page de profil

utilisateur

ElggUser

Un utilisateur du système

site

ElggSite

Le site servi par l’installation Elgg

Chacun a sa propre API étendue. Par exemple, les objets ont un title (titre) et une description, les utilisateurs ont un username (nom d’utilisateur) et un moyen de définir leur mot de passe, et ainsi de suite.

Sous-types (subtypes)

Chaque entité dispose également d’une chaîne personnalisée subtype (sous-type), que les plugins utilisent pour spécialiser davantage l’entité. Elgg facilite la recherche de sous-types spécifiques et leur attribue des comportements et des vues spécifiques.

Les sous-types sont le plus souvent donnés aux instances d’ElggObject pour désigner le type de contenu créé. Par exemple, le plugin blog crée des objets avec le sous-type "blog".

Pour des raisons historiques, l’API des sous-types est un peu complexe, mais se résume à : écrivez sur ->subtype avant d’enregistrer, ou sinon toujours lire getSubtype(). Voici plus de détails ci-dessous.

Trucs à savoir sur les sous-types

  • Avant que la méthode save()``d’une entité ne soit appelée, le sous-type peut être défini en écrivant une chaîne sur la propriété ``sous-type.

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

  • Après enregistrement, vous devez toujours utiliser getSubtype() pour le lire.

  • Si aucun sous-type n’a été défini, "" est retourné, cependant certaines parties de l’API Elgg (comme les vues Views) peuvent mapper cette valeur à la chaîne default. Par exemple, un groupe avec getSubtype() === "" sera rendu à l’aide de la vue group/default.

  • Lisez attentivement la documentation de elgg_get_entities() avant d’essayer de faire correspondre les sous-types ; ceci

  • L’API est un peu un champ de mines. Par ex. vous ne pouvez pas utiliser "" pour récupérer les entités avec le sous-type par défaut.

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 Elgg focntionnenet avec des GUIDs au lieu d’objets ElggEntity.

ElggObject

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

Au-delà des propriétés standards de ElggEntity, ElggObjects 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.

ElggUser

Le type d’entité ElggUser représente les utilisateurs au sien d’une installation Elgg. Il 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, ElggUsers supporte également :

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

  • username Leur nom d’utilisateur. Par ex. « hjackman »

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

  • email Leur adresse email

  • language Leur code de langue par défaut.

  • code Leur code de session (déplacé vers une table séparée dans la 1.9).

  • last_action Le timestamp UNIX de la dernière fois qu’ils ont chargé une page

  • 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 les sites au sein de votre installation Elgg. La plupart des installations n’en ont qu’un seul.

Au-delà des propriétés standards de ElggEntity, ElggSites 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, ElggGroups 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’un forum de discussion et d’une page de profil qui relient les utilisateurs au contenu dans le 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.

ElggGroup pouvant être sous-typé comme toutes les autres entités Elgg, vous pouvez avoir plusieurs types de groupes en cours d’exécution sur le même site.

Écrire un plugin conscient des groupes

Les développeurs de plugins ne devraient pas trop s’inquiéter d’écrire une fonctionnalité consciente des 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 can_write_to_container pour déterminer si l’utilisateur actuel a ou non le droit d’ajouter du contenu à un groupe.

Soyez attentif au fait que vous allez devoir passer le GUID du conteneur ou le nom d’utilisateur à 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) {
    if (!can_write_to_container($user->guid, $container_guid)) {
        // register error and forward
    }
} else {
    $container_guid = elgg_get_logged_in_user_guid();
}

$object = new ElggObject;
$object->container_guid = $container_guid;

...

$container = get_entity($container_guid);
forward($container->getURL());

Identifiants et appartenance des pages

Les groupes ont un nom d’utilisateur simulé de la forme group:GUID, dont vous pouvez obtenir la valeur en récupérant $group->username. Si vous passez ce nom d’utilisateur à une page par son URL via la variable username (c.-à-d. /votrepage?username=group:nnn), Elgg enregistrera automatiquement ce groupe comme étant le propriétaire de la page (sauf si cela est surchargé par la suite).

Jongler entre utilisateurs et groupes

En fait, [[Engine/DataModel/Entities/ElggGroup|ElggGroup]] simule la plupart des méthodes de [[Engine/DataModel/Entities/ElggUser|ElggUser]]. Vous pouvez récupérer l’icône, le nom, etc. en utilisant les mêmes appels, et si vous demandez les contacts du groupe, vous récupérez ses membres. Ceci a été designé spécifiquement pour que vous puissiez alterner entre groupes et utilisateurs aisément dans votre code.

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 à, ou modifier cette entité.

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 : Ceci n’est pas toujours vrai. Les entités Commentaires sont contenues par l’objet commenté, et dans certains plugins tierce-partie la conteneur peut être utilisé pour modéliser des relations parents-enfants entre entités (par ex. un objet « dossier » qui contient un objet 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 ou un entier)

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

  • Un propriétaire

Comme pour les métadonnées, les valeurs sont stockées sous forme de chaines de caractères à moins que la valeur donnée soit un entier PHP (is_int($value) vaut true), ou à moins que $vartype soit spécifié manuellement comme integer.

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' or 'integer'
)

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

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

Lire les 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’aide 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 entité 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 :

  • Une métadonnée a un propriétaire et un ID d’accès (voyez la note ci-dessous), qui peuvent être différents du propriétaire de l’entité à laquelle ils sont attachés

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

  • Comme pour les annotations, les valeurs sont stockées sous forme de chaîne de caractères à moins que la valeur donnée soit un entier PHP (is_int($value) vaut true), ou à moins que le $value_type soit défini manuellement comme integer (voyez ci-dessous).

Note

La valeur de métadonnée access_id est ignorée à partir de Elgg 3.0 et toutes les valeurs de métadonnées sont dès lors disponibles dans tous les contextes.

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 :

  • Le propriétaire est assigné à l’utilisateur actuellement identifié

  • Les autorisations d’accès sont héritées de l’entité (voir la note ci-dessous)

  • 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’id d’accès d’un ElggObject, vous devez l’enregistrer, faute de quoi la modification ne sera pas conservée dans la base de données.

Note

La valeur de métadonnée access_id est ignorée à partir de Elgg 3.0 et toutes les valeurs de métadonnées sont dès lors disponibles dans tous les contextes.

Lire les 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 aurez besoin d’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 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;

Contrôle plus fin

Ajouter des métadonnées

Si vous avez besoin de plus de contrôle, par exemple pour affecter un ID d’accès autre que la valeur par défaut, vous pouvez utiliser la fonction create_metadata, qui est définie comme ceci :

function create_metadata(
    $entity_guid,           // The GUID of the parent entity
    $name,                  // The name of the metadata (eg 'tags')
    $value,                 // The metadata value
    $value_type,            // Currently either 'text' or 'integer'
    $owner_guid,            // The owner of the metadata
    $access_id = 0,         // The access restriction
    $allow_multiple = false // Do we have more than one value?
    )

Pour les valeurs uniques, vous pouvez donc écrire des métadonnées comme suit (en prenant l’exemple d’une date de naissance attachée à un utilisateur) :

create_metadata($user_guid, 'dob', $dob_timestamp, 'integer', $_SESSION['guid'], $access_id);

Note

$access_id sera ignoré dans Elgg 3.0 et toutes les valeurs de métadonnées seront disponibles dans tous les contextes. Toujours le définir sur ACCESS_PUBLIC pour garantir la compatibilité avec Elgg 3.0.

Pour des valeurs multiples, vous devrez itérer et appeler create_metadata sur chacune. Le morceau de code suivant provient de l’action d’enregistrement du profil :

$i = 0;
foreach ($value as $interval) {
    $i++;
    $multiple = ($i != 1);
    create_metadata($user->guid, $shortname, $interval, 'text', $user->guid, $access_id, $multiple);
}

Notez que le paramètre allow multiple est défini sur false dans la première itération et true par la suite.

Lire les métadonnées

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

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

elgg_get_metadata(array(
    'metadata_name' => 'dob',
    'metadata_owner_guid' => $user_guid,
));

Ou pour récupérer toutes les objets des métadonnées :

elgg_get_metadata(array(
    'metadata_owner_guid' => $user_guid,
    'limit' => 0,
));

Erreurs courantes

« Ajouter » des métadonnées

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 :

« {subject} est un {noun} de {target}. »

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 » 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 à n’importe quel niveau de privilège, avec l’avertissement que les entités d’une relation peuvent être invisible en raison du contrôle d’accès !

Travailler avec des relations

Créer une relation

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

// option 1
$success = add_entity_relationship($user->guid, 'fan', $artist->guid);

// option 2
$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 « $utilisateur est un fan de $artiste »:

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

Notez que si la relation existe, check_entity_relationship() retourne un objet ElggRelationship :

$relationship = check_entity_relationship($user->guid, 'fan', $artist->guid);
if ($relationship) {
    // use $relationship->id or $relationship->time_created
}

Supprimer une relation

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

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

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, $was_removed vaudra false.

Autres fonctions utiles :

  • delete_relationship() : supprimer par ID

  • remove_entity_relationships() : supprime ceux qui sont liés à une entité (note : dans les versions avant Elgg 1.9, ceci ne déclenchait pas d’événement delete)

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é, annotation et élément de métadonnée 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 (value: 1) Logged in users.

  • ACCESS_PUBLIC (value: 2) Public data.

  • ACCESS_FRIENDS (valeur : -2) Propriétaire et ses contacts.

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

Vous pouvez définir des groupes d’accès supplémentaires et les affecter à une entité, une annotation ou des métadonnées. Un certain nombre de fonctions ont été définies pour vous aider; voir la documentation de référence sur les 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 et ses cousines 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 surcharger ce comportement en utilisant un hook plugin appelé permissions_check, qui passe l’entité en question à toute focntion qui a annoncé qu’elles veut être référencée. Retourner true va autoriser l’accès en écriture ; retourner false va l’interdire. Voyez les références des plugin hook pour les permissions_check pour plus de détails.

Voir aussi

Référence de la bibliothèque d’accès

Schéma

La base de données contient un certain nombre de tables primaires et de tables secondaires. Le schéma des tables est stocké dans /engine/schema/mysql.sql.

Chaque table est préfixée par « prefix_ », ceci est remplacé par le framework Elgg pendant l’installation.

Tables principales

Voici la description des tables principales. Gardez à l’esprit que pour une installation d’Elgg données 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 peuplée avec votre premier site.

Elles 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 Une référence vers la table entity_subtypes table, ou 0 pour le sous-type par défaut.

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

  • site_guid Le site auquel l’entité appartient.

  • 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 la date de création de l’entité.

  • time_updated Le timestamp UNIX de la date de mise à jour de l’entité.

  • enabled Si oui (“yes”) l’entité est accessible, si non (“no”) 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)

Table : entity_subtypes (sous-types d’entités)

Cette table contient les informations sur les sous-types d’entité :

  • id Un compteur.

  • type Le type d’entité - object, user, group ou site.

  • subtype Le nom du sous-type sous forme de chaîne (string).

  • class Nom de classe facultatif, si ce sous-type est lié à une classe

Table : metadata

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

  • id Un compteur.

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

  • name_id Lien vers la table metastrings définissant la table de noms.

  • value_id Lien vers la table metastrings définissant la valeur.

  • value_type La classe de la valeur, soit texte (text) ou un entier (integer)

  • owner_guid Le GUID du propriétaire qui a défini cet élément de métadonnées.

  • access_id Contrôles d’accès sur cet élément de métadonnées.

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

  • enabled Si oui (“yes”) l’élément est accessible, si non (“no”) l’élément a été supprimé.

Table : annotations

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

  • id Un compteur.

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

  • nom_id Un lien vers la table metastrings définissant le type d’annotation.

  • value_id Lien vers la table metastrings définissant la valeur.

  • value_type La classe de la valeur, soit texte (text) ou un entier (integer)

  • owner_guid Le GUID du propriétaire qui a défini cet élément de métadonnées.

  • access_id Contrôles d’accès sur cet élément de métadonnées.

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

  • enabled Si oui (“yes”) l’élément est accessible, si non (“no”) l’élément a été supprimé.

Table : relationships (relations)

Cette table définit les 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.

Table : objects_entity (entité de type objet)

Informations supplémentaires spécifiquement relatives aux objets. Ceux-ci sont divisés afin de réduire la charge sur la table de métadonnées et de rendre la différence évidente entre les attributs et les métadonnées.

Table : sites_entity (entités de type site)

Des informations supplémentaires spécifiquement relatives aux sites. Celles-ci sont divisées afin de réduire la charge sur la table de métadonnées et de différencier clairement attributs et métadonnées.

Table : users_entity (entités de type utilisateur)

Des informations supplémentaires spécifiquement relatives aux utilisateurs. Celles-ci sont divisées afin de réduire la charge sur la table de métadonnées et de différencier clairement attributs et métadonnées.

Table : groups_entity (entités de type groupe)

Des informations supplémentaires spécifiquement relatives aux groupes. Celles-ci sont divisées afin de réduire la charge sur la table des métadonnées et de différencier clairement attributs et métadonnées.

Table : metastrings (chaînes de caractères des métadonnées)

Metastrings contient la valeur réelle des métadonnées qui est liée aux tables de métadonnées et d’annotations.

Il s’agit d’éviter de dupliquer des chaînes, d’économiser de l’espace et de rendre les recherches dans la base de données plus efficaces.