Saving custom list which implements java.util.List fails

Hi,

I'm evaluating ObjectDB for storing Objects modeled with Eclipse Modeling Framework (EMF)
and encountered the following problem:

I took the Point-example from the tutorial and added a list-attribute which is declared as java.util.List but the actual Object MyList just extends ArrayList as shown below.

@Entity
public class Point implements Serializable {
    ...
    private List list = new MyList();
    ...

}

public class MyList extends ArrayList {
    // nothing in here
}

But storing the object causes this error message:

Exception in thread "main" [ObjectDB 2.4.7_08] javax.persistence.RollbackException
Failed to commit transaction: Attempt to store an instance of a non persistable type tutorial.MyList - field tutorial.MyPoint.list (error 613)
at com.objectdb.jpa.EMImpl.commit(EMImpl.java:290)
at tutorial.TestMyList.main(TestMyList.java:21)
Caused by: javax.persistence.PersistenceException: com.objectdb.o.UserException: Attempt to store an instance of a non persistable type tutorial.MyList - field tutorial.MyPoint.list
at com.objectdb.o._PersistenceException.b(_PersistenceException.java:47)
at com.objectdb.o.JPE.g(JPE.java:142)
at com.objectdb.o.JPE.g(JPE.java:78)
... 4 more
Caused by: com.objectdb.o.UserException: Attempt to store an instance of a non persistable type tutorial.MyList - field tutorial.MyPoint.list
at com.objectdb.o.MSG.d(MSG.java:61)
at com.objectdb.o.TYW.writeElement(TYW.java:250)
at com.objectdb.o.UMR$S.A(UMR.java:995)
at com.objectdb.o.UMR.z(UMR.java:565)
at com.objectdb.o.UML.u(UML.java:537)
at com.objectdb.o.MMM.af(MMM.java:1047)
at com.objectdb.o.UTY.aF(UTY.java:1226)
at com.objectdb.o.UTY.aE(UTY.java:1215)
at com.objectdb.o.ENH.a(ENH.java:46)
at com.objectdb.o.STA.T(STA.java:512)
at com.objectdb.o.STM.E(STM.java:425)
at com.objectdb.o.OBM.bL(OBM.java:903)
at com.objectdb.jdo.PMImpl.bL(PMImpl.java:2192)
at com.objectdb.o.OBM.bK(OBM.java:819)
at com.objectdb.o.OBM.bI(OBM.java:734)
at com.objectdb.jpa.EMImpl.commit(EMImpl.java:287)
... 1 more

I thought this would be possible, or am I doing something wrong?

The background is that EMF has for some Java-elements such as List, Map, etc. it's own analog elements EList, EMap, etc.

An EList inherits from or implements java.util.List but has some additional methods such as for swapping elements position in the list.

So can the above problem be solved with ObjectDB or has anyone experiences with saving EMF-objects with ObjectDB?

With best regards,

Thomas

Entity classes cannot extend Java collection types.

Consider composition instead of inheritance. i.e. the MyList entity class will implement java.util.List and will have a reference to java.util.ArrayList instance as a persistent field.

Thanks for the fast response,

but I don't know if I described the problem the right way because it can't get solved with objectDB while with db4o or Hibernate there are no problems.

So I try again describing the problem.

Note: I've posted the code as Stack Trace, because when tagged as Java Code the background-color doesn't get shown as marking but as html-text inside code.

In db4o and in Hibernate Entities can have various list implementations, as long as they are declared as java.util.List

So the same example runs with db4o and Hibernate but not with objectDB, although the chapter about Multi Value Types sounds that it should be possible:

... For example, the Arrays.asList method returns an instance of an internal Java collection type that is not supported by ObjectDB. Nevertheless, the following entity can be stored

@Entity
public class EntityWithList {
    private List<String> words = Arrays.asList("not", "ArrayList");
}

@Entity
public class Point implements Serializable {
    ...
    private List<Point> friends = new MyList();
    ...

}

Maybe the core question:

So shouldn't it be possible to store any kind of list, as long as it is an instance of java.util.List? Because it doesn't matter how the list is implemented as long as you can get and set the list-elements as defined in the List-interface.

The problem with the recommendation in your post is that we are not in control of 'MyList' since it is legacy code from the Eclipse Modeling Framework.

We are still evaluating objectDB and I'm thankful for your help.

With best regards,

Thomas

Please try build 2.4.7_18, which enables persisting collections and maps of user defined classes.

Notice, however, that similarly to the Arrays.asList example from the manual, this change will enable persisting collections of maps of non standard types, but when retrieved, other collection and map types will be used.

Hopefully this would be good enough for your needs.

My old-version (2.4.7_08)

After installing the new version(2.4.7_18):

1) my recent db-file, created with the old-version, has been copied to the local folder of the new version automatically

2) But I can't open the db-file with the objectDB explorer, neither with the old-version, nor with the new version.

The error message is:

Failed to construct an instance of java.lang.Object using a no-arg constructor.

3) But I can open the db-file programatically (from within my code) and: it works :)

4)To your comment below:

[....] this change will enable persisting collections of maps of non standard types, but when retrieved, other collection and map types will be used.

    Does objectDB work a kind of this way?:

    - It fetches the list-members to a list A whatever of kind (maybe objectDB-intern)

    - It then gets the list B of the users entity object

    - It fills List B with the entries of List A

    -> so if it works similar to this it will be no problem, but if somehow the internal list gets replaced fully by another list (without filling the elments on bye on) it could cause problems later on.

So the items 1-2 could be interesting for migrating from one version to another.

And overall, thanks again for your fast help. It pushes objectDb to the top, except for another task. But for this I'll open a new thread.

Thanks a lot and with best regards,

Thomas

Just tried the Explorer of the new build with old database files and couldn't get the exception. Please provide a full stack trace (from the log), and check the database with the ObjectDB Doctor. But please do that in a separate thread in the issue tracking.

> if somehow the internal list gets replaced fully by another list (without filling the elements on bye on) it could cause problems later on.

This is the way that most JPA implementations work.