triggers et champs calculés
Salut, Je pense qu'il serait bon d'introduire la notion de tiggers et de champs calculés dans wikitty. J'aime pas trop le terme trigger, ca fait un peu trop BD ;) Je prefere le terme listener sur le WikittyServiceStorage. Les champs calculés =================== les champs calculés seraient ajoutés à la déclaration de l'extension. Il pourrait-être de plusieurs sortes: - request: on indique la requête à jouer pour remplir ce champs avant de retourner l'objet. (Probleme: comment faire avec le cache ? on rejoue ou non la requete, lorsqu'on redonne l'objet provenant du cache ?). Peut-être prévoir une méthode refresh sur le wikitty pour ces champs ? - readonly: les champs existent, mais en lecture seul pour l'utilisateur. les données sont produites et mises en place par un trigger qui les utilises. - java/onStore: les champs existent, mais en lecture seul, et sont remplis par l'appel de la classe Java associée au moment du store - java/onRestore: les champs existent, mais en lecture seul, et sont remplis par l'appel de la classe Java associée au moment du restore L'idée est que toutes ces types fonctionnent sur la partie api wikitty et non pas sur une implantation specifique (Solr, JDBC, ...) Voyez-vous d'autre type de fonctionnalité possible ? exemple:: Wikitty someobjects [0..*] javaOnStore=org.nuiton.wikitty.Compute Wikitty root readonly=true Wikitty parents [0..*] readonly=true Wikitty tree [0..*] request="TreeNode.name:('toto' OR 'titi')" Faut-il un tag explicite computed=true, ou seulement javaOnStore, request, ... suffisent ? Est-ce que request ne serait pas en fait un javaOnRestore qui aurait un argument qui serait la requête ? Wikitty tree [0..*] javaOnRestore="org.nuiton.wikitty.ComputedFieldRequest(\"TreeNode.name:('toto' OR 'titi')\")" ou Wikitty tree [0..*] javaOnRestore="org.nuiton.wikitty.ComputedFieldRequest javaParam="TreeNode.name:('toto' OR 'titi')" Les trigger/listeners ===================== Les listeners seraient prévenus lors du Store et du Delete. Il y aurait deux types de listener: - les listeners bloquants (qui travail avec le thread d'appel) - les listeners non bloquants qui utilise un thread distinct pour rendre la main rapidement. Pour ajouter l'un ou l'autre sur le WikittyServiceStorage, on utilise les mêmes méthodes, mais les listeners n'implantent pas la même interface. WikittyServiceListener et WikittyServiceThreadedListener. Ces listeners aurait accès au Service constituant le WikittyServiceStorage (storage et indexer). Mais il serai bon, qu'il travail avec l'interface de ces services et ne présume pas de l'implantation (ex: SolR). Il faudra donc potentiellement enrichir l'api pour cela. Par exemple si on souhaite mettre en Listener l'implantation de l'indexation des TreeNode, cela n'est pas vraiment possible actuellement, car trop proche de SolR (Peut-on vraiment faire autrement ?) Je ne pense pas qu'il faille étendre les listeners a tous les WikittyService. Car si l'on souhaite ajouter un traitement lors de l'appel du store sur le WikittyServiceCache, je pense qu'il est préférable de créer un nouveau type de WikittyService que l'on intercalera avant ou après le WikittyCache et on surcharge la méthode store. Ce mécanisme est celui utilisé actuellement pour implanter les fonctionnalités. La différence entre un champs calculé de type java/onStore et un trigger est que le trigger a vision sur tous les objets du store, alors que le champs calculé, ne connait pas les autres objets qui sont en train d'être storé en même temps que lui. De plus, il sont toujours bloquant. Les choses que l'on pourrait implanter avec ce mécanisme: - indexation des arbres - indexation des autorisations pour permettre un check plus rapide et plus simple des droits Vous avez d'autres idées ? Interrogation: je ne sais pas si les listeners non bloquants sont vraiment via (implantable) sans probleme insoluble -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
Le 07/02/2011 19:58, Benjamin POUSSIN a écrit :
J'aime pas trop le terme trigger, ca fait un peu trop BD ;)
J'ai pas vu la référence. Moi ça me fait plutot penser à de l'électronique mais bon on va pas chipoter :D.
Les champs calculés ===================
Faut-il un tag explicite computed=true, ou seulement javaOnStore, request, ... suffisent ?
je pense qu'ils doivent suffire.
Est-ce que request ne serait pas en fait un javaOnRestore qui aurait un argument qui serait la requête ?
Ca me semble mieux, ça enlève un truc de plus à connaitre pour maîtriser le tout.
Les trigger/listeners =====================
La différence entre un champs calculé de type java/onStore et un trigger est que le trigger a vision sur tous les objets du store, alors que le champs calculé, ne connait pas les autres objets qui sont en train d'être storé en même temps que lui. De plus, il sont toujours bloquant.
Ok, parce que jusque là pour moi c'était le même chose...
Les choses que l'on pourrait implanter avec ce mécanisme: - indexation des arbres - indexation des autorisations pour permettre un check plus rapide et plus simple des droits
Vous avez d'autres idées ?
Oui, pour des trucs métiers dans des applis qui utilisent wikitty ;) Globalement j'ai envie de dire cool, ça risque de simplifier pas mal certains bouts de code et va permettre d'imaginer de nouvelles choses/utilisations. Et permettre d'être plus souple. Par contre, il faut faire attention à ce que que ça reste bien 'déconnectable' simplement pour que l'utilisateur lambda qui n'en a pas besoin ne se retrouve pas noyé dans une usine à gaz. Wikitty, à la base, doit servir à masquer à l'utilisateur la complexité de la problématique des modèles volatiles et facilement changeables. Si on fait un framework super compliqué, on a perdu ;). My 2 cents. Jean
Le 07/02/2011 19:58, Benjamin POUSSIN a écrit :
Salut,
Je pense qu'il serait bon d'introduire la notion de tiggers et de champs calculés dans wikitty.
J'aime pas trop le terme trigger, ca fait un peu trop BD ;) Je prefere le terme listener sur le WikittyServiceStorage.
listener c'est bien, sinon il y a hook :-) Listener me fait même penser à une notion d'abonnement à des files de messages ce qui me parait pas mal. Un object avec un champs calculé pourrait s'abonner aux changements des objets entrant dans le calcul du champs calculé, et rien qu'à ces objets. Le problème de la notion de message c'est pour les hook bloquant ou synchrone ... peut-être ajouter un second message envoyé à la fin du re-calcul du champ ? Et on peut très bien avoir plusieurs type de messages, ou plusieurs file par objet : onStore, onDelete, onUpdate, etc. -- Thomas Clavier http://www.tcweb.org Jabber/XMPP/MSN/Gtalk : tom@jabber.tcweb.org +33 (0)6 20 81 81 30 +33 (0)950 783 783
Le 07/02/2011 19:58, Benjamin POUSSIN a écrit :
Salut,
Je pense qu'il serait bon d'introduire la notion de tiggers et de champs calculés dans wikitty.
J'aime pas trop le terme trigger, ca fait un peu trop BD ;)
Je trouve ça tout à fait adapté, Wikitty est une base de données, autant que les gens s'y retrouvent en essayant de reprendre le vocabulaire pour des notions apparentées non ? (Je suppose que tu voulais dire « ça fait trop relationnel » ;))
Wikitty tree [0..*] request="TreeNode.name:('toto' OR 'titi')"
C'est quoi ce langage dans lequel tu exprimes ta requête dans le request= ? solR ? -- Brendan Le Ny <bleny@codelutin.com> Code Lutin
Le 08/02/2011 18:32, Brendan Le Ny a écrit :
Wikitty tree [0..*] request="TreeNode.name:('toto' OR 'titi')"
C'est quoi ce langage dans lequel tu exprimes ta requête dans le request= ? solR ?
On m'indique que oui. Du coup la requête serait spécifique à l'implémentation du WikittySearchEngine. -- Brendan Le Ny <bleny@codelutin.com> Code Lutin
On Mon, 7 Feb 2011 19:58:32 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Salut,
Je pense qu'il serait bon d'introduire la notion de tiggers et de champs calculés dans wikitty.
J'aime pas trop le terme trigger, ca fait un peu trop BD ;) Je prefere le terme listener sur le WikittyServiceStorage.
Au final, le terme Hook a ete choisi. Et l'implantation a ete faite d'une facon completement differente :). Le principe a été d'ajouter un nouveau WikittyServiceHook dans la pile des WikittyService. Ce WS surcharge toutes les méthodes de modification (store, delete, clear, ...). Un nouveau type WikittyHook a ete crée qui contient entre autre champs - un actionToHook qui indique sur quelle action on souhaite ajouter un hook - le hook en lui meme qui est un script (ex: js, groovy, ...) Le WSHook avant de faire l'action recherche tous les WikkityHook qui portent sur cette action prefixe de 'pre' ex: pre-store. Et les execute. La meme chose est fait apres l'action avec par exemple post-store. Le script a acces au WikittyHook qui le contient, au WS sous-jacent, au argument de la methode (qu'il peut modifier s'il le souhaite), au resultat de la methode s'il s'agit d'un WikittyEvent. Cette implantation permet de mettre en place des champs calcule ou des triggers. Bien sur si une application oublie de stocker les WikittyHook ou de mettre dans la pile de WS le WikittyServiceHook, rien ne se passera :) L'implantation de ce mecanisme a ete simple et est non intrusif. Par contre c'est pas encore testé :). Donc voyez vous des choses qui pourrait coincer ? ou des choses auquel j'aurais pas pensé ?
Les champs calculés =================== ... Faut-il un tag explicite computed=true
Le hook, peut modifier n'importe qu'elle champs d'un objet qui est en train d'être stocké. Mais peut-etre est-ce tout de meme bien que ces champs soient marqués pour par exemple pour interdire leur modification en dehors du WikittyServiceHook (je ne sais pas encore comment faire) ou tout simplement pour qu'on sache que c'est un champs calculé. exemple d'implantation d'un "pre-store": // On met a jour la date d'un extension pour tous les wikitties qui ont // cette extension for w in wikitties: if LastModifiedTimeHelper.hasExtension(w): LastModifiedTimeHelper.setDate(w, new Date()) ...
Les trigger/listeners ===================== ... - les listeners bloquants (qui travail avec le thread d'appel) - les listeners non bloquants qui utilise un thread distinct pour rendre la main rapidement.
Toutes les executions de Hook sont bloquante. Si un Hook souhaite etre non bloquant cela reste a sa charge ex: new Thread() { // ecriture de du code a executer }.start(); Dans ce cas, il ne doit pas chercher a modifier les arguments de la methode ...
Les choses que l'on pourrait implanter avec ce mécanisme: - indexation des arbres
Je ne suis pas sur qu'on puisse avec cette implantation faire cela
- indexation des autorisations pour permettre un check plus rapide et plus simple des droits
Par contre, on peut tres bien imaginer un Hook qui cree toutes les bonnes permission pour les nouveaux objets, ou qui fait d'autres travaux lors de la creation d'une personne, l'ajout d'une personne a un group, la sauvegarde d'une securite, ... -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
On Mon, 7 Feb 2011 19:58:32 +0100 Benjamin POUSSIN <poussin@codelutin.com> wrote:
Salut,
Je pense qu'il serait bon d'introduire la notion de tiggers et de champs calculés dans wikitty.
Au final, le terme Hook a ete choisi. Et l'implantation a ete faite d'une facon completement differente :).
Pas grand chose à voir avec les triggers que tu voulais au départ. Je préfère de loin cette nouvelle approche et le terme hook me semble tout à fait adéquat. -- Brendan Le Ny Code Lutin
participants (4)
-
Benjamin POUSSIN -
Brendan Le Ny -
Jean Couteau -
Thomas Clavier