Reprise du message précédent :

 
question jpa / orm  
 
je suis à la recherche d'un article, ou d'un blog qui exposeraient des pattern pour spécifier proprement les collections lazy que je veux fetcher de ma base  
 
par exemple : j'ai ma classe livre et plusieurs collections 'review/commentaires/dispos/séries/traductions'
 
et suivant certains cas, je veux pas tout retourner, d'autre fois seulement une selection précise de ces catégories  
 
comment vous faites vous ?

 
Je suis pas sûr de comprendre ce que tu cherches à faire, mais au cas où, je vois deux possibilités :
- tu restes en lazy et tu retournes au cas par cas (donc tu appliques tes filtres dans l'appli) ;
- pour tes requêtes spécifiques, tu créé des named queries correspondantes (donc c'est la DB qui applique tes filtres).

merci mais c'est effectivement pas mon problème je me suis ma exprimé.
 
les collections de mon entity sont toutes en lazy (j'y peux rien).
je cherche une méthode souple pour ne pas avoir à me taper toutes les méthodes du types :
 
findBookWithReviewWithoutComment
 
je pense pas que ce soit un truc de criteria, je pense surtout que j'ai peu de moyen de le faire tant que tout est en lazy

Euh, et si tu te creais une interface fluent du genre:
findBook().withReview().fetch()

je regarde lambdaj en ce moment en effet
 
 
merci

Puisqu'il y a du monde aujourd'hui, envoyer des mails à partir d'une appli serveur (web), JavaMail ou autre ?
J'ai pour le moment pas besoin d'autre chose que du mail texte et une connexion SMTP (éventuellement sous SSL), mais qui peut le plus...

Ca peut etre une solution deportee? Genre MailChimp? Ou bien c'est avec votre propre SMTP?
Et sinon, avec resource JNDI ou pas?

Pour le moment, je tape sur un SMTP local. A terme, je n'exclue pas les SendGrid and co.
Je ne connaissais pas MailChimp. De ce que j'en comprend, l'API te permet aussi de constituer ton message, c'est pas un simple SMTP provider ?
Si c'est le cas, et au moins dans un premier temps, je souhaite rester sur du relai SMTP, j'ai l'impression de m'enfermer dans une dépendance importante avec une solution comme MailChimp.

Nope.
 
 

j'ai un brol qui envoie des mails (texte et html) en supportant les pièces jointes basé sur JavaMail, SMTP local.

je ne sais pas si il y a mieux mais c'est simple et il ne m'a jamais fait faux bond sur au moins un bon million de mails envoyés.

 
OK, donc solution maison qui s'appuie sur JavaMail.
C'est le genre d'API tellement vieille - j'ai toujours utilisé que ça - qu'un petit tour d'horizon s'impose de temps en temps. Je connais d'ailleurs pas d'autre implem de la 919.

ça marche bien et simplement... pourquoi réinventer la roue

JPA et collections en Lazy.
 
Si j'initialise ma collection :

@Entity
public class Foo {
    ...
    @OneToMany(fetch = FetchType.LAZY)
    private List<Bar> bars = new ArrayList<Bar>();
}

 
pour notamment éviter les NPE ou null check rébarbatifs lorsque je load la collection, oui, non, Obiwan ?
 
Un thread sur SO aborde la question, avec notamment une remarque (la seule, mais également la réponse acceptée et aucune contre argumentation derrière) contre la pratique :

 
Le problème, bien que pertient dans le cas général, ne me parrait pas applicable lorsque le champ en question est une collection. Je me trompe ? Vos avis généraux sur le chargement des collections en lazy ?

Et pendant que j'y suis, une deuxième, histoire de vous laisser le choix
 
J'ai une hiérarchie d'héritage sur des entités, qui peuvent être stockées dans une collection.
 

@Entity
public class Foo {
    @OneToMany(targetEntity = Bar.class)
    private List<Baz> bazs;
    @OneToMany(targetEntity = Bar.class)
    private List<Buz> buzs;
}
 
@Entity
@Inheritance(strategy = InheritanceType.JOINED) // J'ai essayé avec de la STI également
public abstract class Bar {
    // Plein de champs communs à tous les fruits, à commencer par l'ID
    @ManyToOne
    private Foo foo;
}
 
@Entity
public class Baz extends Bar {
    ...
}
 
@Entity
public class Buz extends Bar {
    ...
}

 
 
Vous connaissez une méthode pour pouvoir appeler foo.getBuzs() sans avoir l'intégralité des Bar retournés ? Dans les deux cas (STI et JOINED), j'ai toutes les entrées.
Et si dans 'targetEntity, je spécifie les classes concrètes, je me fait jeter, j'imagine à cause de l'absence de la clé foo_id dans la table correspondante, mais je pensais le truc assez intelligent pour aller le piocher dans la classe parente.

@Entity
public class Foo {
    @OneToMany(targetEntity = Bar.class)
    private List<Baz> bazs;
    @OneToMany(targetEntity = Bar.class)
    private List<Buz> buzs;
}
 
@Entity
@Inheritance(strategy = InheritanceType.JOINED) // J'ai essayé avec de la STI également
public abstract class Bar {
    // Plein de champs communs à tous les fruits, à commencer par l'ID
    @ManyToOne
    private Foo foo;
}
 
@Entity
public class Baz extends Bar {
    ...
}
 
@Entity
public class Buz extends Bar {
    ...
}

 
 
Perso j'ai une classe AbstractActor
 

 
et plusieurs classes qui en dérivent :  

 
et ensuite dans une autre classe je me prends plus la tête :  

 
et après je recharge l'entity suivant sa nature que ce soit un professional ou un une org, mais tu peux séparer professionnal et org directement
 
 
edit :  
sinon si tu tiens à garder ton JOINED ou STI, tu fais par exemple pour la requête retournant des Baz

 
 
mais j'aime pas

 
Oui, je vois le principe mais tu te doutes bien, je partais sur STI ou JOINED pour éviter les réplications de colonnes dans les tables.
 
Pour le select, oui Sauf qu'effectivement, je trouve ça plus joli de ne passer que par mon bean, plutôt qu'un appel sur DAO.

Pour ceux qui l'auraient oublié ce week-end, deux questions comme on en voit trop peu

(pas spécialement critique, mais avoir vos avis là dessus me permettrait de passer au stade supérieur de la sérénité)

(ça me les brise un peu plus, j'ai pas envie de faire le choix entre une base dégueu et une couche d'accès aux données dégueu)

 
Trouvé une méthode, au cas où ça serve à d'autre. On part du principe que l'on fait de la STI dans notre cas.
La première étape est de dire à Hibernate de bien prendre en compte le type concret de la classe demandée lors du repéchage de la collection, c.-à-d.
 

List<Bar extends Foo> bars;
getBars() // Renvoi bien la liste des Bar, et non pas l'intégralité des Foo

 
Ça revient à ce que l'implémentaton JPA ajoute bien au select un WHERE type = Bar, ce qui n'est pas réalisé par défaut. Il n'existe pas de solution pur JPA, j'ai trouvé ça dans le cas d'Hibernate. On utilise @DiscriminatorOptions(force = true) (anciennement @ForceDiscriminator) sur la classe englobante, et ça roule, le WHERE prend en compte le type de classe concrète demandée. Vous trouverez un peu plus de détail ici : http://www.gmarwaha.com/blog/2009/ [...] riminator/
 
Ce n'est cependant pas terminé. Dans mon cas  
 

@Entity
public class User {
    @OneToMany(mappedBy = "user", targetEntity = Alert.class}
    private List<Alert> alerts;
}
 
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "type" )
@DiscriminatorOptions(force = true)
public abstract Event {
    private User user;
}
 
@Entity
@DiscriminatorValue("ALERT" )
public class Alert extends Event {
}

 
Le champ utilisé comme référence entre Alert et User est déclaré dans le supertype. Apparamment, Hibernate ne sait pas s'en débrouiller, une solution est de déplacer la clé dans une classe - abstraite ou non - qui s'intercale ici entre Event et Alert, annotée avec @MappedSuperclass :  
 

@Entity
public class User {
    @OneToMany(mappedBy = "user", targetEntity = Alert.class}
    private List<Alert> alerts;
}
 
@Inheritance(strategy = InheritanceType.SINGLE_TABLE)
@DiscriminatorColumn(name = "type" )
@DiscriminatorOptions(force = true)
public abstract Event {
}
 
@MappedSuperclass
public abstract UserEvent extends Event {
    private User user;
}
 
@Entity
@DiscriminatorValue("ALERT" )
public class Alert extends UserEvent {
}

 
Et, jusqu'ici, on est bon ! C'était pourtant simple  

En EJB 3.0, vous connaissez un moyen portable / générique de faire du lookup JNDI (hors module Spring, un truc dans le JDK quoi) ? Appli EJB 3.0 sur un application server tout vieux (JBoss 5.1), client Java.
 
En plus de me contraindre à embarquer une context factory spécifique au runtime, le Jar de dépendances client JBoss est immonde, embarque quasiment tout le serveur d'application. Je peux toujours jouer sur un Jar purgé, des exclusions ou autres trucs crados, mais au cas où il y aurait une solution propre...

 
Fun fact: sur une SheevaPlug, la génération / comparaison de mot de passe avec le nombre d'itérations le plus bas prend 16s    
Je sais bien que c'est justement le but, mais je me suis demandé pendant 10 bonnes minutes pourquoi ça ramait autant après déploiement.
 

Mais putain!? Les annotations peuvent être "inheritées" sur les classes/sous-classes, mais pas sur les interfaces implementées ? wtf ?
 

J'ai googlé pour avoir le détail, le premier résultat est pas mal : http://stackoverflow.com/a/4745820

Et réponse suivante pour la spec.

/TIL

Edit : c'était quoi le besoin ?

Jai effectivement vu cette réponse, et ça tient la route, mais ça fait chier, dans la mesure ou mon annotation n'a pas de paramètres. Pis l'API est relativement moisir. Enfin, disons plutôt inexistante. Du coup faut se taper l'itération "à la main" dans les super classes et interfaces, et à priori la seule lib "util" qui tienne la route est dans spring. Donc monolithique, donc non merci. Tout ce que j'ai trouvé d'autre c'est des bouts de code à copier-coller. J'ai pas encore regardé les commons-lang récent mais j'ai des à priori sur les versions up to 2.x; j'espérais trouver qqch dans guava mais non.  

Et ça (pas encore testé), ça ne t'irait pas? https://code.google.com/p/reflections/

tiens, j'y ai pas pensé. J'avais vu cette lib quand j'avais besoin de "chercher" des classes annotées. Le projet à été mis de coté et j'ai oublié la lib; effectivement y'a ptet des choses à y réutiliser sans pour autant passer par le "scanner". Cela dit entre temps j'ai piqué un bout de code qui a l'air de marcher pour mon utilisation, et j'ai buté dans d'autres problèmes avec mon idée qui font que je vais ptet devoir oublier l'annotation et repasser par une interface...
Je serais presque tenter de "tricher" et injecter l'interface via un proxy ...après tout, ça serait une interface avec une seule methode, et utilisée uniquement par le biniou qui processe l'annotation (au runtime).
 
... Biniou qui, d'ailleurs, va possiblement etre un module guice, qui va proxifier les objets annotés en question ...

Je sens que la réponse va me passer au dessus de la tête, mais qqun pourrait expliquer pourquoi je dois caster ici:

et pas la:

Sur le 1 : je dirais que c'est purement du runtime, et que ton compilo n'a aucun moyen de savoir que le cast est inutile.
 
Sur le 2 : t'as une vérif at compile time que n hérite au moins de Number
 
edit; je pense que le vin ne m'attends pas trop : http://en.wikipedia.org/wiki/Generics_in_Java generics en java c'est des vérifs compile time.
 
Après pendant un temps y avait des gars qui voulait plus de souplesse.
Je sais pas où ça en est.

J'ai trouvé, mais c'est pas évident à taper sur mobile donc ça sera pour une autre fois

Bon y'a rien pour proxifier du bordel dans Guice ? C'est quoi que je vois pas là ?
(je veux proxifier toute classe marquée par une annotation)
(et les MethodInterceptor me suffisent pas)
(je fais un topo demain si y'a des curieux, mais surtout si y'a des pistes)

bah si, pourquoi le method interceptor te convient pas ?

Paske

On dirait - mais je suis pas sur à 100%, parce que le cambouis est quand même bien épais la dedans - qu'ils peuvent pas être interdépendants. Le weaving se fait au démarrage, les proxys incomplets créés par le premier sont jamais passés au second et vice-versa. Pas évident à expliquer, encore moins sous mobile, et franchement j'ai pas super envie de passer mon temps a extraire un example.
Détail pas insignifiant, je peux pas faire de binding sur un type.

 
Si la question est de créer le proxy sans avoir à gérer le loading des classes annotées et si Guice intègre Guava, t'as Reflection.newProxy().

Nope, mais je vais voir ça qd mm
Edit: ouais non créer un proxy ça va je sais faire c'est dire à guice de le faire (ou de wrapper une instance) que je sais pas

tu veux proxifier des methodes privees ? si oui tu vas en effect avoir des problemes parce que Guice genere des sous classes au runtime. (idem si tes classes ou methodes sont final, ca va pas passer, pour ce genre de choses il te faut du bytecode injection et le java agent qui va bien, donc aspectj et consort)

Noooon.

Cette semaine, j'ai fait du bit-shifting, de la reflection sur generics, un peu d'AOP et du cache : résultat, le truc qui m'a le plus emmerdé - et pas qu'une fois - c'est l'impossibilité d'avoir des méthodes ou champs statiques et abstraits    
 
/my-blog

Aop avec quoi? J'en chie tjs avec mes proxy moi grrr

Une maquette avec Spring AOP malheureusement. Si j'avais plus de temps et si une réécriture complète devait être faite, je serais parti sur Guice, que je n'ai pas encore testé.
 
C'est pour une API qui mappe une norme et que les équipements interfacés n'implémentent pas tous au même degré.

   
je serai curieux de voir ton use case parce que ca n'a pas grand sens

 
Y'a peut-être du design flaw, mais pour cette API particulière, je me suis retrouvé coincé relativement souvent.
Par exemple garantir que les implem de Foo ont toutes une factory method avec la même signature, définissent toutes le même champ statique...

mais tu pas les invoquer de facon polymorphique, donc ca ne presente aucun interet, a moins que tu utilises la reflection, auquel cas, ouais mauvais design, clairement

Putain on sent le mec qui bosse chez Google hein pour guice si ct à refaire j'éviterais. Trop rigide, et imbitable quand faut rentrer dans le cambouis. Soit je repartirais chez mes vieux potes de picocontainer soit je jetterais un œil sur les nouveaux venus (celui de chez square leadé par crazybob, donc, et un autre dont le nom m'échappe la)