JPA & Ebean ORM: Empty collection is not empty

I've started switching over a project from hand-written JDBC ORM code to Ebeans. So far it's been great; Ebeans is light and easy to use.

However, I have run into a crippling issue: when retrieving a one-to-many list which should be empty there is actually one element in it. This element looks to be some kind开发者_C百科 of proxy object which has all null fields, so it breaks code which loops through the collection.

I've included abbreviated definitions here:

@Entity
class Store {
    ...
    @OneToMany(mappedBy="store",cascade=CascadeType.ALL,fetch=FetchType.LAZY)
    List<StoreAlbum> storeAlbums = new LinkedList<StoreAlbum>();
}

@Entity
class StoreAlbum {
    ...
    @ManyToOne(optional=false,fetch=FetchType.EAGER)
    @JoinColumn(name="store_id",nullable=false)
    Store store;
}

The ... are where all the standard getters and setters are. The retrieval code looks like this:

Store s = server.find(Store.class)
            .where()
            .eq("store_id",4)
            .findUnique();

Assert.assertEquals("Sprint",s.getStoreName());
Assert.assertEquals(0, s.getStoreAlbums().size());

The database is known to contain a 'store' row for "Sprint", and the 'store_album' table does not contain any rows for that store.

The JUnit test fails on the second assertion. It finds a list with 1 element in it, which is some kind of broken StoreAlbum object. The debugger shows the object as being of the type "com.lwm.catalogfeed.domain.StoreAlbum$$EntityBean$test@1a5e68a" with null values for all the fields which are declared as nullable=false (and optional=false).

Am I missing something here?

Thought I'd post an update on this... I ended up giving up on EBeans and instead switched the implementation over to use MyBatis. MyBatis is fantastic; the manual is easy to read and thorough. MyBatis does what you expect it to do. I got it up and running in no time.

EBeans didn't appear to detect that the join for the associated collection resulted in a bunch of null ids, but MyBatis handled this scenario cleanly.

I ran into the same issue and was able to solve it by adding an identity column to the secondary table (StoreAlbum). I did not investigate the cause but I suppose Ebean needs a primary key on the table in these kind of situations.