Re: Issue with distinct 3.1
So really there is little to no use for setDistinct in a SelectQuery. Anyway I was more concerned about the Where clause, I can assure that I am using a non null owner but even then owner is a User object so there is no reason why Cayenne should try to match agains a Contact and distinct should not change the where clause in this query. For reference Contact entity has 3 attributes: + contactOwner : relationship with User + contactTarget: relationship with User + idcontact: AI PK Andrus if you want I can open a Jira Issue Ramiro El 13/11/2013 8:00, Andrus Adamchik escribió: Cayenne forces DISTINCT in the generated SQL whether you specify it or not because it detects a match on to-many relationship and realizes that it needs to get rid of duplicates in the cartesian product. So I guess explicit DISTINCT shouldn’t normally be needed. As to why NULL is bound in the DISTINCT case, this could either be a yet unknown bug in the framework, or something in the app code. Andrus On Nov 13, 2013, at 1:15 AM, Aristedes Maniatis a...@maniatis.org wrote: On 13/11/2013 3:59am, Ramiro Aparicio wrote: I am really not sure if current behaviour without distinct is ok, but at least it works for me. Cayenne returns a collection of objects that will never have duplicates. In fact you can choose whether the results return as a Set, List or Map. Ari -- -- Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Issue with distinct 3.1
So really there is little to no use for setDistinct in a SelectQuery. I think so too. Other than some messed up DB with de-facto non-unique PK, I can’t think why that would be needed. Andrus if you want I can open a Jira Issue Yes please. And I wonder if we should just deprecate ‘distinct’ as a solution. Andrus On Nov 13, 2013, at 1:05 PM, Ramiro Aparicio ramiro.apari...@prot-on.com wrote: So really there is little to no use for setDistinct in a SelectQuery. Anyway I was more concerned about the Where clause, I can assure that I am using a non null owner but even then owner is a User object so there is no reason why Cayenne should try to match agains a Contact and distinct should not change the where clause in this query. For reference Contact entity has 3 attributes: + contactOwner : relationship with User + contactTarget: relationship with User + idcontact: AI PK Andrus if you want I can open a Jira Issue Ramiro El 13/11/2013 8:00, Andrus Adamchik escribió: Cayenne forces DISTINCT in the generated SQL whether you specify it or not because it detects a match on to-many relationship and realizes that it needs to get rid of duplicates in the cartesian product. So I guess explicit DISTINCT shouldn’t normally be needed. As to why NULL is bound in the DISTINCT case, this could either be a yet unknown bug in the framework, or something in the app code. Andrus On Nov 13, 2013, at 1:15 AM, Aristedes Maniatis a...@maniatis.org wrote: On 13/11/2013 3:59am, Ramiro Aparicio wrote: I am really not sure if current behaviour without distinct is ok, but at least it works for me. Cayenne returns a collection of objects that will never have duplicates. In fact you can choose whether the results return as a Set, List or Map. Ari -- -- Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
Re: Issue with distinct 3.1
With regards to: I wonder if we should just deprecate distinct as a solution. What about making it a no op ? With the Java doc explaining that it does nothing because Cayenne forces DISTINCT in the generated SQL whether you specify it or not because it detects a match on to-many relationship and realizes that it needs to get rid of duplicates in the cartesian product. (Andrus) So really there is little to no use for setDistinct in a SelectQuery. I think so too. Other than some messed up DB with de-facto non-unique PK, I cant think why that would be needed. Andrus if you want I can open a Jira Issue Yes please. And I wonder if we should just deprecate distinct as a solution. Andrus On Nov 13, 2013, at 1:05 PM, Ramiro Aparicio ramiro.apari...@prot-on.com wrote: So really there is little to no use for setDistinct in a SelectQuery. Anyway I was more concerned about the Where clause, I can assure that I am using a non null owner but even then owner is a User object so there is no reason why Cayenne should try to match agains a Contact and distinct should not change the where clause in this query. For reference Contact entity has 3 attributes: + contactOwner : relationship with User + contactTarget: relationship with User + idcontact: AI PK Andrus if you want I can open a Jira Issue Ramiro El 13/11/2013 8:00, Andrus Adamchik escribió: Cayenne forces DISTINCT in the generated SQL whether you specify it or not because it detects a match on to-many relationship and realizes that it needs to get rid of duplicates in the cartesian product. So I guess explicit DISTINCT shouldnt normally be needed. As to why NULL is bound in the DISTINCT case, this could either be a yet unknown bug in the framework, or something in the app code. Andrus On Nov 13, 2013, at 1:15 AM, Aristedes Maniatis a...@maniatis.org wrote: On 13/11/2013 3:59am, Ramiro Aparicio wrote: I am really not sure if current behaviour without distinct is ok, but at least it works for me. Cayenne returns a collection of objects that will never have duplicates. In fact you can choose whether the results return as a Set, List or Map. Ari
Re: Issue with distinct 3.1
On 13/11/2013 3:59am, Ramiro Aparicio wrote: I am really not sure if current behaviour without distinct is ok, but at least it works for me. Cayenne returns a collection of objects that will never have duplicates. In fact you can choose whether the results return as a Set, List or Map. Ari -- -- Aristedes Maniatis GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
