Mailing-List: contact open-jpa-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: open-jpa-dev@incubator.apache.org
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:mime-version:in-reply-to:references:content-type:message-id:content-transfer-encoding:from:subject:date:to:x-mailer:sender;
        b=QTymaj0jpiD3pr0TYMyeVktHEtYFHvYrE8M5o0Cj5xfHgppAmHHQjiDV9c2Jonj1B1baFJ8x/+0mK2SqQAcdgfjRZPAHMiYiWBQOGph4oxHS2ge75332mQ2HUkc7alZqhHJ3raGllEaO6YNZbhrqenQ6LUfsL1RZ5muH1/FaDic=
Mime-Version: 1.0 (Apple Message framework v752.3)
In-Reply-To: <49BF64BA795F6A498EC2F04F39BAA8D3D97E62@ptint5.peacetech.com>
References: <49BF64BA795F6A498EC2F04F39BAA8D3D97E62@ptint5.peacetech.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <80C43C70-52FF-423E-852B-6865C1BD82BA@apache.org>
Content-Transfer-Encoding: 7bit
From: Marc Prud'hommeaux <mprudhom@apache.org>
Subject: Re: Proposal: Optimizing empty collection fetch. Meta Column in
 ContainerFieldMappling
Date: Thu, 5 Oct 2006 17:19:02 -0700
To: open-jpa-dev@incubator.apache.org
Sender: Marc Prud'hommeaux <mprudhomapache@gmail.com>

Alex-

That does sound like a good feature to add. Note that I think the  
"null-indicator" attribute is only available for embedded mappings,  
not for container mappings (although I could be wrong about this).

I'd recommend opening a JIRA issue as a reference for the enhancement  
request, and we can build on that.


On Oct 5, 2006, at 3:52 PM, Roytman, Alex wrote:

> Hello Abe,
>
> I would like to present a valid use case and a very useful performance
> enhancement.
>
> The idea is that, if we know that a collection field is empty there is
> no need to fetch it.
>
> It can provide a truly dramatic performance improvement when in a  
> large
> set of instance only some of them have non-empty collection field.
> Consider a very common case - composite (tree like) data structures.
> Unlike true composite pattern typical tree structure does not have a
> special leaf class that is any node of a tree can potentially have
> sub-nodes. When traversing such a tree as many as 70% of fetches of
> child nodes will yield empty collection because obviously leaf  
> level is
> the larges in a tree structure :-)
>
> I wrote a prototype custom 1-N mapping which allow to store "empty"  
> flag
> (whether the collection is empty) on commit and will store empty
> collection into StateManager on collection field load if the flag  
> is set
> to true (empty) instead of going to database to fetch it.
>
> The results were dramatic - when traversing 800-node tree number of
> "fetch-sub-nodes" SQL statements was cut from 800 to 130.
>
> Non-Tree cases when objects have sparsely populated collection  
> field can
> be even more dramatic.
>
> If concurrency of the collection field is controlled on owned class
> level (default) I think there is no dander of this flag being out of
> synch with actual collection content without entering concurrent
> modification state.
>
> I have not had chance to think through transaction commit implications
> if any.
>
> There is a very nice facility in ContainerFieldMappling for indicating
> null container fields. I wonder why it so much hard wired to empty/ 
> null
> and does not allow non-empty/empty/null differentiation and
> optimization.
> Any reason it is so restrictive? Any plans to make it a bit more
> flexible or directly implementing the behavior I outlined above?
>
> I would greatly appreciate if you could comment on this and may be
> suggest the best approach implementing this. Or may be it is already
> implemented and I am missing it :-)
>
> Best Regards
>
> Alex Roytman
> Peace Technology, Inc
>
>