Hi,

I am seeing what looks like cartesian join behaviour in a system I am working on. There is a map consisting of a 100x100 grid. Each grid location may contain objects. An object has a OneToOne relationship with a Grid object and vice versa. When I try to load all the Grid objects (using simple HQL - see below) memory usage seems to be:

size of grid x (num objects ^ 2).

as opposed to what I expected:

size of grid + (num objects * size of object).

Size of grid is huge, size of object is small

Is there a simple mistake I might have made that can lead to this kind of behaviour? It looks like a classic cartesian join, but I have no idea how this condition might be caused using Hibernate.

Thanks,
Matt

Hibernate version:
3.2.1GA + 3.2.1GA Annotations

Mapping documents:
Using Annotations

Code between sessionFactory.openSession() and session.close():
Session session = HibernateUtil.getSession();
Query q = session.createQuery("from com.madeye.darkcity.model.map.Grid where map_id = 1 and z = 0");
List list = q.list();
session.close();

Full stack trace of any exception that occurs:
java.lang.OutOfMemoryError

Name and version of the database you are using:
MySql 4.1.15

I have isolated the problem a little: the Grid is a red herring, the problem lies with the hierarchy of objects. The following HQL exhibits the same problem:

from com.madeye.darkcity.model.object.MonsterObject

However, the Grid is supposed to be a lightweight object - the object it points to should not be loaded with the Grid. So, the original query should have worked (i.e. not loaded any objects). Does CascadeType.ALL force the loading of objects in a similar way to FetchType.EAGER?

The single query above generated about 270k of SQL. I know that this Grid structure will fit in memory as when the objects are first created it all works fine. It's only when the state is restored from the database. I have put the output here:

http://www.madeye.com/obj_test.html

as it's too large to post. If anyone can take a look and point out any obvious mistakes I'd be most grateful.

Thanks,
Matt