RE: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi Armin, Tested what you described and the ordering seems to work in our setup as well. What does not work however is that I get duplicate items returned. For every match in the right-handside of the 1:N relation, I get the same object returned. Even if I execute a distinct query. Also the

Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi Roger, Janssen, Roger wrote: Hi Armin, Tested what you described and the ordering seems to work in our setup as well. What does not work however is that I get duplicate items returned. For every match in the right-handside of the 1:N relation, I get the same object returned. Even if I

RE: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi Armin, Just to make it absolutely clear so we talk about the same thing; When I execute a reportquery, I expect to get records back, and if I get duplicate records back because of the joins I created, well that is fine. But when I execute a 'normal' query, and OJB returns instantiated

Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi Roger, Janssen, Roger wrote: Hi Armin, Just to make it absolutely clear so we talk about the same thing; When I execute a reportquery, I expect to get records back, and if I get duplicate records back because of the joins I created, well that is fine. But when I execute a 'normal' query,

Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi Roger, I start work on OJB-137 (your issue) and noticed while playing with order-by tests that the following notations seems to work (class Book has a 1:n relation to class Review): Criteria c1 = new Criteria() .addEqualTo(reviews.summary, 3_review + name); c1.setAlias(alias_1);

Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi Roger, I create two new user-alias related bug reports: http://issues.apache.org/jira/browse/OJB-137 https://issues.apache.org/jira/browse/OJB-139 OJB-137 reflects your issue. Locally I fixed OJB-139 (easier to fix then 137) and start work on OJB-137 (seems more complex to fix).

Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi Roger, now I get your point (I'm a bit slow on the uptake ;-)). I start writing many new order by tests to isolate the problem and to make sure that changes don't have unrequested side-effects. itself was not stable enough for us). In fact, I helped implementing this feature in OJB a

RE: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi, The management summary answer to your question is it important to support alias-names in order by and having clause is : Yes, it is really really really important!!! So now for some background information explaining our situation. We implemented a concept to support non-modelled (abstract)

Re: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi Roger, Janssen, Roger wrote: Hi, When you have two object classes, Permit and AbstractAttribute and Permit holds a collection of AbstractAttributes (using a collection descriptor for the abstractattribute collection on the Permit in the mapping file), we can create a query like below:

RE: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi, In a response to my own patch I send, it may have a bug in it It replaces the useralias in the orderby so 'myAlias.value' becomes 'A1.value' and then further standard processing adds 'A1.value as ojb_col_xx' to the select-columnlist in the query. Bu as you notice the column name 'value'

RE: BUGREPORT : OJB 1.0.5rc1 : UserAliases in OrderBy clauses are not replaced by the generated aliases for the joins resulting in illegal SQL statements

Hi again, The problem is real but the patch I described (see original message) is flawed. So forget that patch. I think the solution direction is probably something like: - pas the useralias to the ensurecolumns methods (they should pass it on, but now they do not have it and they pass null,