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. Selecting enum (the hidden mdd's field name) leads to a java reserved keyword problem	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.
SELECT x > y FROM...	BUG, HQL error	selecting logical expression	HQL cannot directly select logical expressions, so using mak:if is a problem HQL understands things of the kind "case when (logical expression) then 1 else 0 end".	FIXED. mak:if now adopts this syntax when translating the query
SELECT a.b.c FROM A a...	BUG, generated SQL misses a comma in the FROM section		HQL has problems with multiple dereferencing	FIXED in the last Hibernate version
SELECT x as y FROM z ORDER BY y	BUG, HQL error	group by statement using labels	HQL does not support the possiblity of using labels in the ORDER BY clause.	FIXED by a workaround that replaces the label by its expression, ie. SELECT x as y FROM z ORDER BY x. We should watch if the next Hibernate releases will deal with this.
SELECT a FROM b WHERE b.name=$someParam	SELECT a FROM b WHERE b.name=:someParam	Different way of marking an attribute, "$" vs ":"	Still to be decided whether we want to keep it like this, or enforce $ and translate it. However, the general policy was to use HQL directly and not to translate into it.	Do nothing.
SELECT p.id FROM test.Person p	SELECT p.id FROM test.Person p	Selecting fied with special name	In Hibernate .id is a reserved element, used when declaring the primary key in mappings. In some MDDs, there are however fields called "id" which confuse Hibernate when selected normally.	Don't allow "id" in MDDs
SELECT p.name FROM test.Person p WHERE p.hobby = 'sailing'	SELECT p.name FROM test.Person p WHERE p.hobby = 10	parameter type	In OQL, 'sailing' is translated into its database value. In Hibernate, this is not the case yet, intEnum being specific to Makumba	Extend the HQL analyzer and perform the translation when needed. Maybe a direct translation in Hibernate could be done while generating the mappings, e.g. public enum EventStatus { FINISHED("Finished, whatever else there was", 10), CANCELLED("Cancelled", 20), SOME_OTHER_STATE(....); private String endUserPresentation; private int dbLevelValue; EventStatus(String s, int n) { endUserPresentation=s; dbLevelValue=n; } }