February 2011 - Wikitty-devel - mailman.cloud.codelutin.com

triggers et champs calculés
by Benjamin POUSSIN April 8, 2011

April 8, 2011

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(a)codelutin.com http://www.codelutin.com

4 6

NPE durant la reindexation
by Eric Chatellier Feb. 24, 2011

Feb. 24, 2011

Bonjour, La reindexation ne fonctionne pas et se termine par une NPE : java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.nuiton.util.ObjectUtil.call(ObjectUtil.java:327) at org.nuiton.util.ApplicationConfig$Action.doAction(ApplicationConfig.java:556) at org.nuiton.util.ApplicationConfig.doAction(ApplicationConfig.java:943) at com.jurismarches.vradi.VradiServiceMain.main(VradiServiceMain.java:52) Caused by: org.nuiton.wikitty.WikittyException: Can't store wikitty at org.nuiton.wikitty.storage.solr.WikittySearchEngineSolr.store(WikittySearchEngineSolr.java:322) at org.nuiton.wikitty.services.WikittyServiceStorage$1.scan(WikittyServiceStorage.java:960) at org.nuiton.wikitty.jdbc.WikittyStorageJDBC.scanWikitties(WikittyStorageJDBC.java:473) at org.nuiton.wikitty.services.WikittyServiceStorage.syncSearchEngine(WikittyServiceStorage.java:947) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.services.WikittyServiceSecurity.syncSearchEngine(WikittyServiceSecurity.java:539) at org.nuiton.wikitty.services.WikittyServiceDelegator.syncSearchEngine(WikittyServiceDelegator.java:192) at org.nuiton.wikitty.WikittyProxy.syncSearchEngine(WikittyProxy.java:1069) at com.jurismarches.vradi.VradiServiceAction.reIndexSolr(VradiServiceAction.java:94) ... 8 more Caused by: java.lang.NullPointerException at org.nuiton.wikitty.storage.solr.SolrUtil.copySolrDocument(SolrUtil.java:220) at org.nuiton.wikitty.storage.solr.SolrUtil.copySolrDocument(SolrUtil.java:271) at org.nuiton.wikitty.storage.solr.WikittySearchEngineSolr.addTreeIndexField(WikittySearchEngineSolr.java:574) at org.nuiton.wikitty.storage.solr.WikittySearchEngineSolr.store(WikittySearchEngineSolr.java:320) ... 18 more J'ai regardé vite fait le code, mais je ne sais pas si le code peut fonctionner en gerant cette valeur null, ou si c'est une erreur. -- Éric Chatellier <chatellier(a)codelutin.com> Tel: 02.40.50.29.28 http://www.codelutin.com

2 6

[ANN] - Wikitty 3.0.4 released
by nuiton.org Release Notification Feb. 15, 2011

Feb. 15, 2011

1 0

Indexation de WikittyAuthorisation (Groups)
by Benjamin POUSSIN Feb. 7, 2011

Feb. 7, 2011

Salut, Sur WikittyAuthorisation ont a des champs qui prennent comme valeur des Users ou des Groups. Les Groups contiennent eux même des Users ou des Groups. L'idée est d'optimiser l'indexation pour mettre la vérification des droits de façon simple. Dans les WikittyAuthorisation on ajoute de nouveaux champs exemple: #group-groups-readers et #group-users-readers qui contiendront respectivement tous les groups et tous les Users du champs readers. De cette façon pour savoir si un User a le droit de faire quelque chose, il suffit de rechercher s'il est dans #group-users-readers. Peut-etre introduire la notion de champs calculé dans Wikitty et s'en servir pour ce besoin ? (comment faire ca ? il faut y reflechir) Si un Group est modifié, on recherche s'il est utilisé dans un Group pour la secu, si c'est le cas on recherche tous les WikittyAuthorisation qui l'utilise et on réindexe cette autorisation. Peut-etre introduire la notion de trigger sur wikitty pour cela ? (comment faire ca ? il faut y reflechir) Je pense qu'a cours terme, on va implanter directement dans l'indexation Solr ce calcul de champs. Mais prevoir que ce code devra sans doute être remplacer par des champs calculés et des triggers lorsque ceux-ci auront été implantés. L'avantage des champs calculé, est qu'on ne modifie pas l'indexation SolR et qu'on reste normalement agnostique a l'implantation du moteur de recherche utilisé. Idem pour les triggers, l'autre avantage des triggers est qu'il pourrait etre de simple listener sur des evenements wikitty (store, delete) et s'executer en tache de fond ou non suivant ce que l'on souhaite). L'implantation des triggers me semble beaucoup plus simple que les champs calculés. Et pourrait etre un premier pas pour faire l'externalisation de fonction qu'on fait rentrer artificielement dans le core. On pourrait meme imagine que l'indexation des arbres se base aussi sur les champs calculés + triggers. -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

2 2