With LEFT JOIN and RIGHT JOIN, it matters what table operation is performed first. Query builder is not as good at figuring out what goes first, and if there are more that two tables it seems not good at creating a plan for the SQL. Consider having the builder allow user to group tables from left to right or top to bottom to give visual cues to builder what table operation should be performed first. Presently, where multiple tables and joins are concerned, only way to ensure desired sequence of execution is to save multiple layered queries, one referencing the other. That leads to too many saved queries. Instead, consider giving user finer control in context of one query (or getting better SQL plans when more than two LEFT or RIGHT JOIN relationships are in play.
Lionel - thoughts on this one? Valid enhancement request?
The execution plan is decided by the database engine, Base (and Query Builder) plays no role in that. I'm not even sure Base can possibly have any influence on that; maybe parenthesising the JOIN expression is taken as a clue by the database engine? Even assuming Base could have an influence, I don't immediately have a good idea of how to present that visually... I don't like the idea of taking the spatial layout left-to-right and/or top-to-bottom because the spatial layout is IMHO purely presentational and not semantic. Maybe we could annotate the link lines with numbers or so. Or have a separate dialog that lists the links (JOINs) and allows to order them. In the absence of visual clue (that is, without this enhancement request being fulfilled), one can "always" go to the SQL view and parenthesise the SQL directly (if the underlying database engine supports that, not all of them do).
The issue is moot anyway for more complex queries, where the builtin SQL parser has to be bypassed in order for the query to execute. Queries of this type can not even be created in the GUI QueryBuilder, let alone represented on screen.
Adding self to CC if not already on
Either we should mark this as wontfix, or else accept it as rfe, knowing that it will probably never be implemented, given the complexity to implement it (even if it is all possible), as indicated by Lionel. For the moment, setting as rfe. Lionel, if you have other thoughts on the matter, please correct as appropriate.