Here are the presently known issues with the makumba - HQL query transition.
Note that all the indicated Makumba queries do pass the HQL parser. They will not however pass the HQL-SQL translator (in the ptr and set join cases) or have a different semantic (in the other cases).
The rightmost column suggests ways to automatically translate the Makumba OQL (once passed by the HQL parser) into HQL that would pass the HQL-SQL translator.
It is interesting to note that a label means different things in the Hibernate FROM and SELECT sections. In FROM, it is a pointer/reference, in SELECT it is a whole object. Makumba is more consistent in this area (hence the suggestions below).

Makumba OQL	Hibernate HQL	problem	comment	suggested resolution
SELECT i.surname, p.weight FROM test.Person p, p.indiv i WHERE i.name = 'Bart'	SELECT i.surname, p.weight FROM test.Person p JOIN p.indiv i WHERE i.name = 'Bart'	ptr and set joining	Hibernate set and pointer joining is not as obvious as in Makumba but most probably more flexible (IN operator more powerful) Generated Hibernate SQL uses JOIN... ON (while  makumba's will use supplementary WHERE conditions, one for pointers, one for sets). Note that this is the case for all kinds of Makumba sets. Instead of JOIN p.indiv i, one can use the equivalent form , IN (p.indiv) i This problem is more important for sets, for pointers you can always use p.indiv instead of i in the SELECT and WHERE expressions.	Accept at JSP level but recommend/train people with the Hibernate form
SELECT s.name FROM test.Person p, p.speaks s WHERE p.indiv.name = 'Bart'	SELECT s.name FROM test.Person p JOIN p.speaks s WHERE p.indiv.name = 'Bart'
SELECT a.streetno FROM test.Person p, p.address a	SELECT a.streetno FROM test.Person p, JOIN p.address a
SELECT p.indiv FROM test.Person p	SELECT p.hibernate_indiv FROM test.Person p	ptr projection	In Hibernate, p.indiv would select the whole test.Individual because Hibernate is oriented towards selecting whole objects, not just fields. The current solution is to map (in the test.Person mapping file) pointers like indiv twice: once as a relation to test.Individual (which allows selection of the whole object) and second as a value with the name hibernate_indiv (which allows selection of the pointer value without joining the test.Individual table). Maybe a better name can be chosen (e.g. indivPtr instead of hibernate_indiv).	Selecting whole objects (<mak:value expr="p.indiv" />) makes little sense at JSP level. Accept the current makumba form and translate into the Hibernate form. NOT sure if the Makumba form should be deprecated (like in other cases)
SELECT p FROM test.Person p	SELECT p.id FROM test.Person p	primary key projection	In Hibernate, p would select the whole test.Person because Hibernate is oriented towards selecting whole objects, not just fields. The current solution is to use the Hibernate-level field name (id) of the Makumba primary key	Selecting whole objects (<mak:value expr="p" />) makes little sense at JSP level. Accept the current makumba form and translate into the Hibernate form BUT but recommend/train people with the Hibernate form.
SELECT s FROM test.Person p, p.intSet s	SELECT s.enum FROM test.Person p JOIN p.intSet s	int/charEnum projection	A combination of set joining and label projection. Selecting s would select the whole enumerator object, which is typically useless.	Accept the current makumba form and translate into the Hibernate form. NOT sure if the Makumba form should be deprecated (like in other cases)
label.field=nil label.field <> nil	label.field is null label.field is not null	null comparisson	Hibernate follows SQL.	While the above Makumba notations are syntactically correct in HQL, this one is probably not. Maybe it's easier to change the existing JSPs.