Project: Wikitty
Code Location: http://svn.nuiton.org/svn/wikitty/trunk/trunk
Browse
/
Download File
TODO.txt
court terme
=========== 
- comment adapter la récupération des extensions "non connue" d'un objet métier.
  - pour WikittyService: restore(id, field or extension name), on differencie field et extension par le .*
   (on doit meme pouvoir faire un simple startWith, ATTENTION si une extension commence par la meme chose qu'une autre
  - dans le proxy: restore(Class, id, all:boolean), si all est true toutes les extensions seront chargees pas seulement celle de Class
  - pour WikittyService: récupérer les dépendances entre extension

- support d'un select en plus du criteria pour etre capable de recuperer
  seulement un champs d'un objet et non pas l'objet en lui meme
- test unitaire sur les upper/lower bound
- retrouver les bons nom des champs pour les noms des facettes

- refaire le storage en mémoire
- stockage de la liste entière dans un champ à améliorer
- refaire des tests

- muplicité à 1 génération de l'attribut à not null
- trie sur champ dans une association

- dans AbstractWikittyService.store, il faut sans doute mettre la mise a
  jour de la version et mettre a false le isDirty et non pas dans les impl
  des storages (En fait il faudrait le faire que lorsque le service est
  attaque en local car en distant c'est au proxy de faire). Et ceci si la
  transaction reussi.

moyen terme
===========
- tests plus importants sur l'import et l'export.
- sérialisation des UUID (en base64 ?)
  (02/09/09) peut-être qu'une sérialisation plus "métier" serait pertinente et pourait tout aussi bien servir d'UUID,
  	exemple : [uuu][ddd][xxxxxxxx...] où uuu est le trigrame de l'utilisateur qui a créé la donnée,
  	ddd est le jour de création de la donnée et xxx... le reste aléatoire de la clé.
  	çà peurrait être assez pratique au quotidien. (ou pas :) 
  stockage des id wikitty dans hbase comme un byte[16] 
  on diviserait par 2 la taille des ID.
- faire de la documentation (avec jean)
- lors du store ne sauve que les fields dirty pour gagner du temps (hbase
  semble reprendre les valeurs des champs deja sauver dans un autre commit
  pour ceux que l'on ne resauve pas car pas modifie)
- ameliorer wikittyUtilTest
- gestion des contraintes sur les champs (mandatory, default value, ...)
- faut-il ou non des exceptions sur le setFieldValue ou un runtime suffit ?
- test de performance 
	- définir des critères pour comparer les différentes implémentations
	- jouer les tests sur un volume de donnée "cible" (qq millions d'attributs)
- implementation de la persistance des listes à revoir (en fonction des tests de perf)  
- organisation des paquetages, à faire après stabilisation

- modification de la generation.
  * suppression du generateur BussinessEntityBeanGenerator (et de toute
    reference a ce genre d'objet dans le code Wikitty)
  * verifier qu'ils ne servent a rien et supprimer: EnumGenerator,
    EugengoConstants, EugengoUtils, InterfaceGenerator.
  * renommer Wikengo* en Wikitty* et BusinessEntity* en Wikitty*