IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Hibernate Java Discussion :

Doit-on toujours mapper exactement la base de donnée?


Sujet :

Hibernate Java

  1. #1
    Membre averti
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 28
    Par défaut Doit-on toujours mapper exactement la base de donnée?
    Salut tout le monde, voilà j'aimerai savoir si on doit toujours mappé à la colonne près les class hibernate?

    Par exemple je veux modélisé des utilisateurs et leurs droits d'accès, comme une base de données. Un utilisateur lambda peut avoir plusieurs droits comme sur ce diagramme de classe


    Par contre mon modèle relationnel ressemble plus à ça, pour des raison évidentes. Un utilisateur à toujours plusieurs droits, par contre, pour un type de droits donnée j'ai un ensemble d'utilisateur.


    Le truc avec hibernate, c'est que si je récupère pour un utilisateur donnée ces droits, alors il va me récupérer tout les utilisateurs ayant les mêmes droits.

    Est - il possible de mappé cette base avec du ManyToOne côté User et OneToMany côté Droit?

    merci

    [EDIT] Mauvaise image de base de donnée

  2. #2
    Membre Expert
    Inscrit en
    Août 2009
    Messages
    1 073
    Détails du profil
    Informations forums :
    Inscription : Août 2009
    Messages : 1 073
    Par défaut
    Il est surtout possible de définir les associations en mode lazy, ie "ne me ramène pas la collection tant que je ne te la demande pas explicitement". Donc le lien entre un droit et la liste des utilisateurs existera, mais ne sera pas initialisé tant que tu n'en auras pas besoin.

    Est-ce que ça te convient, ou bien est-ce que tu veux clairement casser la liaison pour que nulle part dans le code ça ne soit accessible ?

  3. #3
    Membre averti
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 28
    Par défaut
    Merci pour ta réponse, j'avais besoin de quelqu'un pour me confirmer l'utilisation de LAZY.

    Par contre j'ai bien mappé en FETCH.LAZY la méthode getDroits() et getUsers() mais le problème persiste. En fait lors de la création de chaque object Droit, il me récupère tous les utilisateurs ayant le même droit. Je ne comprends pas pourquoi.

    Voici les annotations que j'utilise pour le User
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    @ManyToMany(fetch = FetchType.LAZY)
    @JoinTable(name = "user_a_des_droits", 
    joinColumns = {@JoinColumn(name = "id_user", nullable = false, updatable = false) },
    inverseJoinColumns = {@JoinColumn(name = "id_droit", nullable = false, updatable = false) })
    public Set<Privilege> getDroits() {
    	return this.droits;
    }
    Et pour les droits
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    @ManyToMany(fetch = FetchType.LAZY, mappedBy = "droits")
    public Set<User> getUsers() {
    	return this.users;
    	}
    Et voici le code qui fait appel à la base de donnée
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    @RemotingInclude
    @Transactional
    public User login(String login, String password) {
    // Version criteria
    Criteria criteria = sessionFactory.getCurrentSession().createCriteria(
    		User.class).add(
    		Restrictions.and(Restrictions.eq("login", login), Restrictions
    			.eq("password", password)));
    User user = (User) criteria.uniqueResult();
    return user;
    }
    Merci de votre aide

  4. #4
    Membre averti
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 28
    Par défaut petit up s'il vous plait
    up s'il vous plait

  5. #5
    Membre Expert
    Inscrit en
    Août 2009
    Messages
    1 073
    Détails du profil
    Informations forums :
    Inscription : Août 2009
    Messages : 1 073
    Par défaut
    Comment sais-tu que l'appel ramène tous les utilisateurs associés aux droits ? Tu vois défiler le sql côté console, ou bien tu fais un get sur la méthode java ?

    Parce que dans le dernier cas, il est normal que ça te ramène tout (tant que la session reste ouverte, of course). Le principe du Lazy, c'est bien d'aller chercher le tout quand on en a besoin.

  6. #6
    Membre averti
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 28
    Par défaut
    Parce que je ne fais pas de getDroits(), et avec le debbugger j'ai accès à la liste des utilisateur (users) de l'attribut droit de l'object User.

    Alors que je ne fais aucun appel à getDroits() ni getUsers().

    J'ai l'impression que c'est mon mapping bidirectionnelle qui force la récupération.

    Pour info je suis en architecture 3-tier, ou méthod "login" retourne au front-end l'objet User sous forme de Value Object.

  7. #7
    Membre Expert
    Inscrit en
    Août 2009
    Messages
    1 073
    Détails du profil
    Informations forums :
    Inscription : Août 2009
    Messages : 1 073
    Par défaut
    Le debugger fait exactement comme un getDroits : si tu vas cliquer sur la collection, il y accède, et du coup ramène tous les utilisateurs. Je te conseille pour vérifier ce qui est vraiment ramené dans le cours normal de l'utilisation de ton appli de faire des tests sans le mode debug :

    1. Le plus basique, mettre "show-sql" à true dans la config hibernate, histoire de voir ce qui se passe effectivement. Tu verras alors bien si tu as une liste longue comme le bras d'appels à ta table utilisateur quand tu n'en requête qu'un.

    2. De faire un test basique où tu ramènes ton utilisateur, tu fermes ta connexion, et là tu essaies d'accéder à ta collection d'utilisateurs présente dans ton droit. Tu devrais tomber sur une jolie exception.

    EDIT : pour le cas où ton mode debug concerne ton DTO, il pourrait être judicieux de vérifier que ce que fait ta méthode qui passe de ton objet métier à ton objet de transfert ; en particulier, ça peut très bien être elle qui va chercher la collection en essayant de rattacher au DTO une version DTO des droits, puis de la collection des utilisateurs ...

  8. #8
    Membre averti
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    28
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 28
    Par défaut
    Alors merci pour le show_sql, je ne connaissais pas

    Du coup j'ai essayé et en effet le débugger fait un appel SQL lorsque je déroule un des attribut LAZY.

    Par contre ça devient assez drôle lorsque mon service me renvoi le résultat. Et la c'est la catastrophe. Dans la console toute ma base de donnée est récupérer.

    Le problème vient du fait que j'utilise Flex pour mon frontend (GUI). Plus précisément, c'est la techno BlazeDS lors du retour de fonction. Vu qu'il a besoin de serializer l'objet pour le transmettre sur le réseau, alors il fait appel à hibernate qui ne fait que sont boulot. Ce problème ne peut pas être négligé lors des mapping OneToMany et ManyToMany

    voici les deux articles qui m'ont mis sur la piste (un peu vieux et en anglais)
    http://note19.com/2007/08/26/lazy-in...te-and-spring/
    http://blog.engage-encore.com/index....-lazy-loading/

    Du coup je suis entrain de chercher un moyen pour configurer les framework proposés.

  9. #9
    Membre Expert
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Juin 2007
    Messages
    2 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels

    Informations forums :
    Inscription : Juin 2007
    Messages : 2 938
    Par défaut
    Citation Envoyé par NargiT Voir le message
    Alors merci pour le show_sql, je ne connaissais pas

    Du coup j'ai essayé et en effet le débugger fait un appel SQL lorsque je déroule un des attribut LAZY.

    Par contre ça devient assez drôle lorsque mon service me renvoi le résultat. Et la c'est la catastrophe. Dans la console toute ma base de donnée est récupérer.

    Le problème vient du fait que j'utilise Flex pour mon frontend (GUI). Plus précisément, c'est la techno BlazeDS lors du retour de fonction. Vu qu'il a besoin de serializer l'objet pour le transmettre sur le réseau, alors il fait appel à hibernate qui ne fait que sont boulot. Ce problème ne peut pas être négligé lors des mapping OneToMany et ManyToMany

    voici les deux articles qui m'ont mis sur la piste (un peu vieux et en anglais)
    http://note19.com/2007/08/26/lazy-in...te-and-spring/
    http://blog.engage-encore.com/index....-lazy-loading/

    Du coup je suis entrain de chercher un moyen pour configurer les framework proposés.
    Je confirme, j'ai eu le même comportement en utilisant le framework Dozer, je trouve pas ça super, c'est clairement avancer à réculon que d'être confronté à ce genre de difficulté.

Discussions similaires

  1. Mapper sa base de données avec le pattern DAO
    Par cysboy dans le forum Persistance des données
    Réponses: 20
    Dernier message: 16/08/2022, 21h32
  2. Réponses: 7
    Dernier message: 14/10/2008, 09h34
  3. Réponses: 2
    Dernier message: 25/11/2007, 21h31
  4. doit-on toujours créer des requêtes ?
    Par OBIWAN64 dans le forum Access
    Réponses: 3
    Dernier message: 22/03/2006, 15h37

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo