using DbUnit with ObjectDb

Are there any examples about how to use DbUnit with ObjectDB?

DbUnit requires access to a jdbc connection .. with other providers it's possible to extract the jdbc connection from the EntityManager, e.g. for Eclipselink / Postgres combination you can use the rather long-winded:

IDatabaseConnection connection = new DatabaseConnection(((EntityManagerImpl) (em2.getDelegate())).getServerSession().getAccessor().getConnection(), "PUBLIC");

but with objectDb this gives:

Exception in thread "main" java.lang.ClassCastException: com.objectdb.jdo.PMImpl cannot be cast to org.eclipse.persistence.internal.jpa.EntityManagerImpl

Alternatively, are there better solutions than dbUnit for unit testing and / or loading test data to objectDb from xml files?

if com.objectdb.jpa.EMImpl is the equivalent of Eclipselink's EntityManagerImpl, it doesn't appear to have a method that would return a connection.

Currently ObjectDB doesn't support JDBC connections and the only way to load data is by using JPA or JDO, i.e. by writing code.

It shouldn't be difficult to add to ObjectDB basic support of loading data from XML. Can you provide a sample object model and XML file in the format of your existing XML data? If you do - this could be served for a quick initial implementation of this feature (hopefully in days), which later can be extended to more flexible XML formats.

OK, so we probably can't use test case built with DbUnit.

There may be 2 candidate approaches:
a) DbUnit file approach:

I suppose that there may be quite a few users that have used the DbUnit xml format - actually there are two formats, neither of which have an xsd as far as I know: the first is 'XmlDataSet' - this is quite verbose but does have a DTD (the origin of DbUnit goes way back), but far more commonly used is 'FlatXmlDataSet' which uses attributes for column names instead of elements, for example:

<?xml version='1.0' encoding='UTF-8'?>
<dataset>
  <oe.file_type filetype_id="0" filetype_name="NoFile" info="No file"/>
  <oe.file_type filetype_id="1" filetype_name="UnknownFile" info="Unknown file"/>
  <oe.file_type filetype_id="2" filetype_name="JPEG" mime="image/jpeg" extension=".jpg,.jpeg" info="JPEG image"/>
  ..
</dataset>

second example:
<?xml version='1.0' encoding='UTF-8'?>
<dataset>
  <oe.parameter_type parameter_id="0" parameter_name="Unknown" description="Unknown"/>
  <oe.parameter_type parameter_id="1" parameter_name="Time" description="Time since UNIX epoch" info="Seconds since 00:00:00 UTC on January 1, 1970"/>
  ...
</dataset>

*but* as you can see, the element and attribute names vary from table to table .. not so easy to read via JAXB??

b) Entity driven approach:

JPA entity classes are often automatically annotated with JAXB, so writing lists of entities to xml file should be easy - a generic mechanism to read / unmarshall those files into lists of entities for writing to database may be more ObjectDB / JPA centric?

I got an entity driven approach to work, but couldn't completely generalise it,

each entity needs a wrapper class to enable the writing of a list of entities, for example if Unit is a JPA Entity class we need:

@XmlRootElement
public class Units {
    private List<Unit> list = new ArrayList<>();
    // no-args for jaxb
    public Units() {}
    public Units(List<Unit> unitList) {
        this.list = unitList;       
    }
    // This xmlElement name *must* be the same as the simple name of the Entity class that the list will contain
    @XmlElement(name = "Unit")
    public List<Unit> getList() {
        return list;
    } 
}

I couldn't find a way around having to include the name of the entity as the XmlElement name ..

but, with a few wrapper classes am now reading / writing xml files to / from postgres and ObjectDB ;-)

Using JAXB is a nice idea and I am glad it works for you.

But I think that the main limitation of this approach is that it is limited to small data sets that can fit into the main memory, doesn't it? Can you use it to load many GBs of data? If you load the data set in packs, what happens with you have a reference to an entity object in a future pack that has not been handled yet?