[jpa/hibernate] composite id uit complexe types

[Apache]

Hallo beste p&w'ers,

Ben momenteel wat aan het stoeien met de JPA om van de mapping files af te geraken
en alles met annotations te mappen.

Nu ben ik het volgende probleem tegen het lijf gelopen:
http://forum.java.sun.com...essageID=9552448&tstart=0

Op zich werkt het wel zoals het daar werkt, dus een extra pk aanmaken met daarin de primitieve types,
maar ik had graag gehad dat mijn id gewoon kon bestaan uit de 2 complexe types waarnaar die keys verwijzen.

Hoe ik het nu heb:

Java:

@Entity
@Table(name="buddies")
public class Buddy implements Serializable {
    
    /**
     * 
     */
    private static final long serialVersionUID = -8580361165914133828L;

    @EmbeddedId
    private BuddyPK pk = new BuddyPK();
    
    @ManyToOne
    @JoinColumn(name="initiatorid", nullable=false, insertable=false, updatable=false)
    private Programmer initiator;

    @ManyToOne
    @JoinColumn(name="accepteeid", nullable=false, insertable=false, updatable=false)
    private Programmer buddy;
    
    private Boolean validated = false;
    
    public Buddy(){}

    public Buddy(Programmer initiator, Programmer buddy) {
        super();
        this.initiator = initiator;
        this.buddy = buddy;
        
        // dit vind ik persoonlijk nogal ranzig
        pk.initiatorid = initiator.getProgrammerid();
        pk.accepteeid = buddy.getProgrammerid();
    }

    /* ..... accessor methodes even weggelaten ..... */
    
}

@Embeddable
class BuddyPK implements Serializable {
    /**
     * 
     */
    private static final long serialVersionUID = -6697275691013319892L;
    public int accepteeid;
    public int initiatorid;
}

Wat ik dus ongeveer zou willen is dit:

code:

    @Id
    @ManyToOne
    @JoinColumn(name="initiatorid", nullable=false)
    private Programmer initiator;

    @Id
    @ManyToOne
    @JoinColumn(name="accepteeid", nullable=false)
    private Programmer buddy;

Aangezien hij toch genoeg meta data heeft met de name in de joincolumn om te weten in welke kolom hij het moet opslagen en dmv de @Id in programmer weet hij de value die hij daar moet gaan opslaan.

Wanneer ik dat laatste toepas met dan nog een toegevoegde @Column die +/- hetzelfde bevat als de join column krijg ik serialization & eof errors.

Graag jullie inzichten.

[JKVA]

Je zou het idd willen, maar het zit er idd niet in. Waarschijnlijk om een beetje snel een stabiele versie de deur uit te kunnen doen.

Ik weet niet of het op de planning staat. Denk het niet eigenlijk. JPA is erg geinspireerd door Hibernate en daar beschouwen ze composite ID's als legacy. (beetje mee eens)

edit:

Oja, en die serialization errors en zo zullen wel bugs in glassfish ofzo zijn. Zulke fouten mogen nooit bij de client code komen. Wanneer krijg je die fouten?

[ Voor 22% gewijzigd door JKVA op 01-06-2007 20:39 ]

[Apache]

Ik weet dat jpa sterk gebaseerd is op hibernate, daarom verbaasde het me dat dit er niet inzit terwijl dit met gewone hibernate mappings geen enkel probleem is.

Momenteel run ik enkel wat testjes met junit, gebruik wel spring als achterliggend framework en gebruik mijn eigen lazy test class die overerft van de AbstractDependencyInjectionSpringContextTests:

Java:

package net.homelinux.bbox.util.testing.spring.dao;

// imports

public abstract class HibernateLazyTestCase extends
        AbstractDependencyInjectionSpringContextTests {

    protected SessionFactory sessionFactory;
    
    @Override
    protected void onSetUp() throws Exception {
        super.onSetUp();
        String[] contextLocations = {"WebContent/WEB-INF/applicationContext.xml"};
        
        this.applicationContext = loadContextLocations(contextLocations);
        
        sessionFactory = (SessionFactory) getBean("sessionFactory");
        Session s = sessionFactory.openSession();
        TransactionSynchronizationManager.bindResource(sessionFactory,
                new SessionHolder(s));
        
    }

    @Override
    protected void onTearDown() throws Exception {
        super.onTearDown();

        SessionHolder holder = (SessionHolder) TransactionSynchronizationManager
                .getResource(sessionFactory);
        Session s = holder.getSession();
        s.flush();
        TransactionSynchronizationManager.unbindResource(sessionFactory);
        SessionFactoryUtils.closeSession(s);

    }

    protected Object getBean(String beanName) {
        return this.applicationContext.getBean(beanName);
    }

    @Override
    protected ConfigurableApplicationContext loadContextLocations(String[] locations) {
        if (logger.isInfoEnabled()) {
            logger.info("Loading config for: " + StringUtils.arrayToCommaDelimitedString(locations));
        }
        return new FileSystemXmlApplicationContext(locations);
    }
    
}

Op zich bevalt de jpa mij wel, heb nog niet meteen andere blunders als dit tegengekomen, zijn er nog?

Mogelijk zit het probleem hem dan in de AnnotationSessionFactoryBean van spring.

Jammer, maar niet de eerste api met schoonheidfoutjes

[JKVA]

Ik heb praktisch ook nog niet zoveel gedaan met JPA. Voornamelijk de theorie, voor de certificering.

Dus nog niet echt tegen zwaktepunten aangelopen, los van natuurlijk de duidelijke gevallen zoals het niet hebben van criteria, 2nd level cache, en zo...

Hier mensen die het al in de praktijk hebben kunnen gebruiken?

[ Voor 11% gewijzigd door JKVA op 01-06-2007 23:06 ]