You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Pinaki Poddar (JIRA)" <ji...@apache.org> on 2007/09/08 01:02:30 UTC

[jira] Created: (OPENJPA-358) Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups

Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups
---------------------------------------------------------------------------------------------------

                 Key: OPENJPA-358
                 URL: https://issues.apache.org/jira/browse/OPENJPA-358
             Project: OpenJPA
          Issue Type: Bug
            Reporter: Pinaki Poddar


A field f can have multiple recursion depth specified under different fetch groups.
Give:
 f is a member of three fetch groups A,B and C with d1, d2, d3 being its recursion depth in these groups respectively.

Assertion:
if A and B are active and C is inactive then effective recursion depth of f should be max(d1,d2) and not max(d1,d2,d3).

Currently recursion depth of f does not account for the active groups and is computed over all the groups f is a member of.



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Re: [jira] Commented: (OPENJPA-358) Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups

Posted by Michael Dick <mi...@gmail.com>.
I think we're going with Patrick's (he said it first anyway) approach from
this thread :
http://www.nabble.com/forum/ViewPost.jtp?post=12318494&framed=y

The relevant section follows :

> Since we will have active development on the trunk and on the 1.0
> branch, the release manager for the 1.0.1 release will need to do the
> work of merging desired fixes from the trunk back to the branch.

I think that we should take a different approach: the people who want
particular fixes that were put into trunk should be responsible for
merging them into the 1.0 branch, and the release manager should be
responsible for merging any work that was done only in the 1.0 branch
back into trunk.

So in this case I'm the person who wants these fixes in the 1.0.x branch so
I get to merge them :-)

Naturally if you want to do the merge I won't stop you. I just wanted to
verify that you're done with the changes before I start merging.

-Mike

On 9/18/07, Pinaki Poddar <pp...@bea.com> wrote:
>
> > Is this fix complete in trunk?
>
> Yes.
>
> Does individual committer merges his/her changes or someone centrally
> does it?
>
> Pinaki Poddar
> 972.834.2865
>
>
> >-----Original Message-----
> >From: Michael Dick (JIRA) [mailto:jira@apache.org]
> >Sent: Tuesday, September 18, 2007 3:01 PM
> >To: dev@openjpa.apache.org
> >Subject: [jira] Commented: (OPENJPA-358) Recursion Depth for
> >Field f should be calculated w.r.t active fetch groups and not
> >all fetch groups
> >
> >
> >    [
> >https://issues.apache.org/jira/browse/OPENJPA-358?page=com.atla
> >ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
> >_12528533 ]
> >
> >Michael Dick commented on OPENJPA-358:
> >--------------------------------------
> >
> >Is this fix complete in trunk? If so we should probably get
> >the changes merged into 1.0.x.
> >
> >> Recursion Depth for Field f should be calculated w.r.t active fetch
> >> groups and not all fetch groups
> >>
> >----------------------------------------------------------------------
> >> -----------------------------
> >>
> >>                 Key: OPENJPA-358
> >>                 URL:
> >https://issues.apache.org/jira/browse/OPENJPA-358
> >>             Project: OpenJPA
> >>          Issue Type: Bug
> >>    Affects Versions: 0.9.7, 1.0.0
> >>            Reporter: Pinaki Poddar
> >>            Assignee: Pinaki Poddar
> >>             Fix For: 1.0.1, 1.1.0
> >>
> >>
> >> A field f can have multiple recursion depth specified under
> >different fetch groups.
> >> Give:
> >>  f is a member of three fetch groups A,B and C with d1, d2,
> >d3 being its recursion depth in these groups respectively.
> >> Assertion:
> >> if A and B are active and C is inactive then effective
> >recursion depth of f should be max(d1,d2) and not max(d1,d2,d3).
> >> Currently recursion depth of f does not account for the
> >active groups and is computed over all the groups f is a member of.
> >
> >--
> >This message is automatically generated by JIRA.
> >-
> >You can reply to this email to add a comment to the issue online.
> >
> >
>
> Notice:  This email message, together with any attachments, may contain
> information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
> entities,  that may be confidential,  proprietary,  copyrighted  and/or
> legally privileged, and is intended solely for the use of the individual or
> entity named in this message. If you are not the intended recipient, and
> have received this message in error, please immediately return this by email
> and then delete it.
>

RE: [jira] Commented: (OPENJPA-358) Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups

Posted by Pinaki Poddar <pp...@bea.com>.
> Is this fix complete in trunk?

Yes. 
 
Does individual committer merges his/her changes or someone centrally
does it? 

Pinaki Poddar
972.834.2865
 

>-----Original Message-----
>From: Michael Dick (JIRA) [mailto:jira@apache.org] 
>Sent: Tuesday, September 18, 2007 3:01 PM
>To: dev@openjpa.apache.org
>Subject: [jira] Commented: (OPENJPA-358) Recursion Depth for 
>Field f should be calculated w.r.t active fetch groups and not 
>all fetch groups
>
>
>    [ 
>https://issues.apache.org/jira/browse/OPENJPA-358?page=com.atla
>ssian.jira.plugin.system.issuetabpanels:comment-tabpanel#action
>_12528533 ] 
>
>Michael Dick commented on OPENJPA-358:
>--------------------------------------
>
>Is this fix complete in trunk? If so we should probably get 
>the changes merged into 1.0.x. 
>
>> Recursion Depth for Field f should be calculated w.r.t active fetch 
>> groups and not all fetch groups
>> 
>----------------------------------------------------------------------
>> -----------------------------
>>
>>                 Key: OPENJPA-358
>>                 URL: 
>https://issues.apache.org/jira/browse/OPENJPA-358
>>             Project: OpenJPA
>>          Issue Type: Bug
>>    Affects Versions: 0.9.7, 1.0.0
>>            Reporter: Pinaki Poddar
>>            Assignee: Pinaki Poddar
>>             Fix For: 1.0.1, 1.1.0
>>
>>
>> A field f can have multiple recursion depth specified under 
>different fetch groups.
>> Give:
>>  f is a member of three fetch groups A,B and C with d1, d2, 
>d3 being its recursion depth in these groups respectively.
>> Assertion:
>> if A and B are active and C is inactive then effective 
>recursion depth of f should be max(d1,d2) and not max(d1,d2,d3).
>> Currently recursion depth of f does not account for the 
>active groups and is computed over all the groups f is a member of.
>
>--
>This message is automatically generated by JIRA.
>-
>You can reply to this email to add a comment to the issue online.
>
>

Notice:  This email message, together with any attachments, may contain information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated entities,  that may be confidential,  proprietary,  copyrighted  and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.

[jira] Commented: (OPENJPA-358) Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups

Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/OPENJPA-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12528533 ] 

Michael Dick commented on OPENJPA-358:
--------------------------------------

Is this fix complete in trunk? If so we should probably get the changes merged into 1.0.x. 

> Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups
> ---------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-358
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-358
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 0.9.7, 1.0.0
>            Reporter: Pinaki Poddar
>            Assignee: Pinaki Poddar
>             Fix For: 1.0.1, 1.1.0
>
>
> A field f can have multiple recursion depth specified under different fetch groups.
> Give:
>  f is a member of three fetch groups A,B and C with d1, d2, d3 being its recursion depth in these groups respectively.
> Assertion:
> if A and B are active and C is inactive then effective recursion depth of f should be max(d1,d2) and not max(d1,d2,d3).
> Currently recursion depth of f does not account for the active groups and is computed over all the groups f is a member of.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (OPENJPA-358) Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups

Posted by "Kevin Sutter (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OPENJPA-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Sutter updated OPENJPA-358:
---------------------------------

        Fix Version/s: 1.1.0
                       1.0.1
             Assignee: Pinaki Poddar
    Affects Version/s: 0.9.7
                       1.0.0

> Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups
> ---------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-358
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-358
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 0.9.7, 1.0.0
>            Reporter: Pinaki Poddar
>            Assignee: Pinaki Poddar
>             Fix For: 1.0.1, 1.1.0
>
>
> A field f can have multiple recursion depth specified under different fetch groups.
> Give:
>  f is a member of three fetch groups A,B and C with d1, d2, d3 being its recursion depth in these groups respectively.
> Assertion:
> if A and B are active and C is inactive then effective recursion depth of f should be max(d1,d2) and not max(d1,d2,d3).
> Currently recursion depth of f does not account for the active groups and is computed over all the groups f is a member of.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (OPENJPA-358) Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups

Posted by "Michael Dick (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/OPENJPA-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Dick resolved OPENJPA-358.
----------------------------------

    Resolution: Fixed

> Recursion Depth for Field f should be calculated w.r.t active fetch groups and not all fetch groups
> ---------------------------------------------------------------------------------------------------
>
>                 Key: OPENJPA-358
>                 URL: https://issues.apache.org/jira/browse/OPENJPA-358
>             Project: OpenJPA
>          Issue Type: Bug
>    Affects Versions: 0.9.7, 1.0.0
>            Reporter: Pinaki Poddar
>            Assignee: Pinaki Poddar
>             Fix For: 1.0.1, 1.1.0
>
>
> A field f can have multiple recursion depth specified under different fetch groups.
> Give:
>  f is a member of three fetch groups A,B and C with d1, d2, d3 being its recursion depth in these groups respectively.
> Assertion:
> if A and B are active and C is inactive then effective recursion depth of f should be max(d1,d2) and not max(d1,d2,d3).
> Currently recursion depth of f does not account for the active groups and is computed over all the groups f is a member of.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.