7.9.2.2. DSL

7.9.2.2.1. Analyse

7.9.2.2.1.1. Présentation

L’objet de cette analyse est de chercher quel pourrait être le langage de requête pour le journal.

A noter : les requêtes doivent disposer de quelques critères libres.

Plusieurs implémentations en ligne de mire possibles :

• Requêtes équivalentes à l’usage dans des collections REST classiques en URL, avec la contrainte VITAM (cela doit être dans le Body)

  • Exemple Projection Google : ?fields=url,object(content, attachments/url)
  • Exemple de recherche classique : ?name=napoli&type=chinese,japanese&zipcode=75*&sort=rating,name&desc=rating&range=0-9

• Requêtes dans le body permettant d’être un peu plus riche et notamment dans la composition :

  • Des classes « Expression » permettent de gérer les différents cas de recherche : AND/OR, Property=value, opérateurs autres (IN, NE, GT, GTE…), NOT…

Un exemple de classes « Expression » :

• Interface Expression;

  • Interface AExpression;

    • Abstract LogicalExpression;

      • Class AndExpression;
      • Class OrExpression;

    • Class PropertyExpression;

  • Interface BExpression;

    • Abstract OperatorExpression;

      • Class EqualExpression;
      • Class GreaterThanExpression;
      • …

    • Class NotExpression;

7.9.2.2.1.2. Explication

Une interface Expression.

2 interfaces AExpression et BExpression.

Une classe abstract LogicalExpression permettant de gérer les expressions logiques AND et OR.

LogicalExpression{
  Operator ope;//(ENUM)
  AExpression exp;
}

Les 2 classes implémentées sont AndExpression et OrExpression. La classe PropertyExpression permet de gérer les requetes sur les champs à proprement parler.

PropertyExpression{
  String propertyName;
  BExpression exp;
}

Une classe abstract OperatorExpression permettant de gérer les opérateurs IN, NE, GT, GTE…

OperatorExpression{
  Operator ope; //(ENUM)
  Scalar|Array value; //(Int, String...)
}

Les classes implémentées sont entre autres InExpression, GteExpression…. La classe NotExpression permet de gérer les expressions NOT.

NotExpression{
  Operator ope; //(ENUM -> NOT)
  BExpression exp;
}

7.9.2.2.1.3. Utilisation

Classe Query pour y intégrer une expression

Query{
  Expression exp;
}

Classe SearchQuery pour y intégrer une liste de Query

SearchQuery{
  List<Query> queries;
}

7.9.2.2.2. Conclusion

Il apparait clairement que - même s’il est compliqué - le DSL Vitam existant est très proche de l’analyse effectuée. Il pourra donc être utilisé pour la recherche dans le logbook, en adaptant les classes Query et Request (ou en adaptant les Helpers associés).

La réutilisation du même DSL va aussi dans le sens de la simplification du point de vue de l’utilisateur des API par l’uniformisation des DSL utilisés.

La recommandation de l’étude porte donc sur la réutilisation du DSL Vitam destiné aux Units et ObjectGroups pour les Journaux.

Néanmoins, il y aura quelques différences (pas de roots, ni de depth).

Additions IT18 : A ce jour, une implémentation du DSL en mode mono-query a été développée : la classe DBRequestSingle. Pour le moment il n’y a pas encore de mutualisation entre le DBRequestSingle et les requêtes Logbook car celles-ci sont encore trop spécifiques.