mysql.sql is the script to set up tables on mysql database.

The data objects with relations to each other are:

1. Department.java
2. Equipment.java
3. Locked.java
4. Reason.java
5. Service.java
6. State.java
7. Supplier.java
8. Type.java

The files with measurement result of different refactorings are:

1. results-....txt

OID.java is a helper class for OID loading strategy.

TestAll.javaexecutes all tests starting with TestCreate.java which creates the test data and ends with TestRemove.java which removes all the test data.

To execute tests with different mappings between the data objects i needed 3 different jdo-conf files and mapping files.

- bi-jdo-conf.xml and bi-mapping.xml are used for test with bidirectional mapping. That means the n-side have a reference to the 1-side and also the 1-side has a reference to the n-side (ArrayList). This jdo-conf and mapping is used at TestLoadBi1toN.java and TestLoadBiNto1.java.
- uni-jdo-conf.xml and uni-mapping.xml are used for test with unidirectional mapping. That means the n-side have a reference to the 1-side but the 1-side has *no* reference to the n-side (ArrayList). This jdo-conf and mapping is used at TestLoadUni1toN.java and TestLoadUniNto1.java.
- lazy-jdo-conf.xml and lazy-mapping.xml are used for test with bidirectional mapping with lazy loading. That means the n-side have a reference to the 1-side and also the 1-side has a reference to the n-side (ArrayList). With this test the objects of the n-side are lazy fetched when accessed. This jdo-conf and mapping is used at TestLoadLazy1toN.java.

The difference between the tests with postfix 1toN and Nto1 is how you access your objects.

- 1toN executes a query to load the objects of the 1-side and then walks through all referenced objects which is the n-side of the relation in this case. E.g. the query returns 10 A objects that each have references to 10 B objects having references to 10 C objects each, which leads to walk over 1000 C objects.
- Nto1 is the other direction. The objects of the n-side are loaded with a query and the code walks all the referenced objects. In above example the query returns all 1000 C objects and accesses the B object referenced by C and also the A objects referenced by B.

A <1----N> B <1----N> C
with 10 A objects
10 x 10 B objects
10 x 10 x 10 C objects

The names of the test methods inside of the test classes are:

- testReadWriteEmpty
  load objects with access mode 'ReadWrite' by standard OQL query, cache is empty when test begins.
- testReadWriteCached
  load objects with access mode 'ReadWrite' by standard OQL query, cache contains all objects that are queried, loaded or accessed duringt the test.
- testReadWriteOidEmpty
  load objects with access mode 'ReadWrite' by OID loading strategy, cache is empty when test begins.
- testReadWriteOidCached
  load objects with access mode 'ReadWrite' by OID loading strategy, cache contains all objects that are queried, loaded or accessed duringt the test.
- testReadOnlyEmpty
  load objects with access mode 'ReadOnly' by standard OQL query, cache is empty when test begins.
- testReadOnlyCached
  load objects with access mode 'ReadOnly' by standard OQL query, cache contains all objects that are queried, loaded or accessed duringt the test.
- testReadOnlyOidEmpty
  load objects with access mode 'ReadOnly' by OID loading strategy, cache is empty when test begins.
- testReadOnlyOidCached
  load objects with access mode 'ReadOnly' by OID loading strategy, cache contains all objects that are queried, loaded or accessed duringt the test.
- testReadOnlyOidOnly
  only execute the query to load OID but do not access any object.

Having said that the queries that need to be executed for the OID loading strategy are passthrough SQL statements.