J'ai un pb qui est le suivant :  
 
J'ai des agents, qui ont des roles (relation 1..* 1..* et chaque coté)
 
logiquement, je pensais mettre une ArrayList en attribut de l'agent, pour stocker les id des roles qu'il possède.
 
Seulement dans cloudscape le mapping crée un type bit varying 1000, et rien qu'en mettant 2 Integer dans une arrayList, on dépasse 1000 caractères...donc je me mange une truncateException ...
 
le pb vient de la base qui gère mal, ou c une limitation des EJB ?
 
au pire je peux faire un bean intermédiaire, qui rappatrie les ID agent et ID roles (comme un MLD quoi) ...

 
C'est pas logique d'un point de vue modélisation EJB/relationnel. Tu es sensé utiliser une CMR (container managemed relationship) et une table intermédiaire dans ta base.

ben je sais pas si t'a regardé, mais mettre une relation fait exactement la meme chose...et ca ne crée par la table intermédiaire...(je bosse en top down)

Si un agent a n roles et un role est attribué à n agents, tu n'as pas d'autres choix pour un modèle relationnel normé que d'utiliser une table intermédiaire.  
 
Qu'entends tu par top down?

ben dans websphere, t'a 3 stratégies de mapping RDB : top down, bottom up, et meet in the middle..
 
la premiere prend les EJB, et crée une table par EJB, ni plus ni moins...la seconde prend les tables d'une base existante, et génère les EJB, et la dernière est un mix des 2 ...
 
le pb aussi c que j'utilise cloudscape, et que c pas pratique du tout

Je pense alors que la génération automatique proposée par websphere ne respecte pas les règles du modèle relationnel.  
 
Généralement je préfère faire le modèle de la base et le modèle EJB à la main.

Oui, le top down c'est bancal à 99%, à moins de savoir très exactement où on va et comment on va y aller. Et là ton problème montre bien que t'es pas dans le 1% et que tu devrais donc faire du bottom-up

je suis d'accord, mais :  
- c un projet final dont le but aie qu'on aie trop de chose à faire pour le temps imparti (y'a un dossier de conception joint ou on doit filer un doc de vision qui explique ce qu'on a arbitré, et pkoi)
- g essayé avec d'autres bases, mais c assez complexe à configurer, et g pas le temps de m'y plonger (g essayé avec SQL server, g paumé une soirée là dessus)
==> j'utilise cloudscape, et c une saloperie à administrer
 
donc j'ai des contraintes que je maitrise pas...si j'avais un poil plus de temps, j'aurai regardé pour mettre DB2, ou un truc du style, faire un joli MLD, et me faire un bottom up dans les règles...
 
mais je préfère avoir un modèle un peu foireux et plus de fonctionnalités à montrer à la soutenance...parce que se greffe sur ce qu'on fait toute une partie d'ECD pour de la détection d'erreurs, et faut que l'appli tourne pour que ce soit possible...

Quelles sont tes contraintes ? Parce que si tu souhaites de la productivité je pense que tu es mal parti avec Websphere, des CMP et Cloudscape.  
 
MySql est fourni avec des outils très pratiques pour l'administration.

en gros :  
on développe une appli qui permet de gérer une usine de traitement de déchets nucléaires...avec tt la sécu que ca implique, une système de gestion des autorisations par role, et le système d'ordre est cloisonné par type de role, et la communication se fait via workflow
(PS : j'emmerde le prochain qui me sort que son buzzword-o-meter a cramé, c le sujet et les technos imposées, je choisis pas)
 
on a toute latitude...le pb c qu'on est surtout "expérimentés" sur du dev d'EJB sur websphere coté métier, avec une présentation web...
 
mais on a 2 semaines à 4, dont seulement 2 codeurs...les 2 autres font de l'ECD, et on se partage la conception, et le suivi du projet...donc infaisable quoi...donc on rush, on part sur ce qu'on connait, parce que pas le temps de partir sur autre chose
 
maintenant comme je l'ai dit, si j'avais le temps, et pas de contraintes, je pense que je me ferais ca sous eclipse, avec les plugins qui vont bien, et je testerai Hibernate, sur une base que je maitrise bien (probablement Firebird ou SQL server)

heu ... un document de vision *après* le projet ?
genre un dossier de fin de projet quoi ...

 
T'es dans la m****!    
 
Le problème est qu'avec vos délais vous n'avez pas beaucoup de temps à perdre sur des problèmes techniques de framework. Vous devez donc les limiter au maximum.  
 
Je pense que tu as intérêt à virer le risque CMP/Cloudscape qui a des chances de vous bouffer énormément de temps. Code la partie persistance de la manière la plus simple qui soit. Tu peux jetter un coup d'oeil à iBatis et notamment à cet article sur son utilisation dans websphere : http://www-106.ibm.com/developerwo [...] 0502cline/
 
Bon courage,
 
Au fait, ça fait longtemps que je suis sorti de l'école, c'est quoi l'ECD?

y'a pas de rapport avec websphere
et c'est pas des strategies de mapping, juste des strategies de generation d'ejb

 
non on le rend en meme temps, mais théoriquement on est cencé l'avoir fait avant...un document de vision quoi...
 

Extraction de Connaissances à partir de Données...l'idée c qu'avec l'appli, y'a une base...que dans la base, t'a des données de prod...l'idée du sujet, c que si qqn est malveillant (et cherche à piquer de la came), ou est mauvais (rate un controle, etc...), un système classique te permet juste de trouver l'erreur (stock réel != stock théorique) ...en mettant en place de l'ECD, tu peux etre plus fin : tu trouves l'erreur, trouve son contexte, et détermine des patterns d'erreur...ce qui te permet à la fin de pouvoir dire que si tu donnes un boulot à Mr Durand, t'a 99.7% de chances qu'il le fasse bien, alors que si tu le donnes à Mr Dupond, t'a que 85.6% ...je te laisse poursuivre le raisonnement en terme de gestion
 

Ben dsl, c ce que g lu dans la doc EJB de websphere...et je te signale que ca peut etre une stratégie de mapping, dans la mesure où ca marche très bien si tu crées les EJB à priori, il te génère les tables qui correspondent...ca marche dans les 2 sens

 
J'imagine que dans ton cas cela se traduit par l'insertion de pas mal de données de contexte autour de tes données métier. J'ai peur que tu aies du mal avec des CMP mais je serai curieux de connaître ton avis à la fin si tu as persisté   dans ce choix.

non, parce que le contexte dont on a besoin peut etre tiré des données métier :  
 
on a une usine qui traite des lots...chaque lot se balade (ordre de transfert, validation du transfert effectué), subit éventuellement un traitement, etc...
 
donc on sait à chaque instant qui a tripoté un lot donné, où, quand, sur l'ordre de qui...donc on peut traver l'erreur, vu que tt est historisé, et tout est cloisonné, et controlé
 
sinon oui g persisté dans les CMP ...mais c aussi que je maitrise rien d'autre pour le moment, et que j'avais clairement pas le temps d'apprendre...mais je suis vacciné de websphere pour les EJB à vie

Vaccines toi des EJB tout court si tu veux mon avis

y'a des aspects intéressants, comme le fait que ca gère le multithreading pour toi...et la synchro qui va bien...c qd meme mieux qu'une servlet non ?

en même temps  
1) une servlet c'est dans le tier de présentation/contrôle
2) le threading des servlet est géré par le serveur web.

je sais bien...
 
donc vous foutez quoi dans le tiers métier si c pas des EJB ? (dans la mesure où on se restreint à java hein)... y m'avait semblé que ct conçu pour...

c'est fait pour, mais on peut imaginer des métiers en pojo, ou dans d'autres trucs (javabeans par ex) ...

 
Personnellement j'utilise spring. Je code le business entre des classes services équivalentes à des EJB stateless et des classes métiers que je persiste via hibernate. Les transactions sont démarquées par déclaration, tomcat me fournit les threads, la synchro des données est répartie entre la base et hibernate.
 
C'est efficace et très productif.
 
Tu peux suivre le lien ci-dessous pour tester en direct.

je connaissais pas Spring...c très utilisé ? (j'arrive pas à me rendre compte de ce qui sert vraiment dans tt la nébuleuse J2EE au sens larget, entre tt les API sun, + ce qu'on trouve ailleurs dans Jakarta ou autre)

Disons qu'il y a des chances qu'EJB 3 ressemble à spring + hibernate (ou jboss4 + hibernate). Autant s'y mettre tout de suite et profiter des possibilités offertes par cette nouvelle proposition d'architecture.