Alex-
You are right about jdbc-container-meta ... I had forgotten about
that attribute.
I can certainly file a JIRA request if you'd like me to.
That's the standard mechanism for entering enhancement requests for
OpenJPA itself, so it is useful to have as a reference point.
I wonder if there is any chance to get some advice on implementing
it in
Kodo JDO 3.4?
Do you mean in addition to your implementation of it for Kodo 4.0?
The custom field mapping mechanism is similar to 4.0, so any work
that you have done for this implementation in 4.0 will probably be
similar to how you would do it in 3.4.
Do you think it is reasonable to expect this feature in 4.1 release?
It probably would not make it in in time.
Is 4.1 coming soon?
Yes, very soon.
Will it have solid JDO2 implementation?
Yes it will.
On Oct 5, 2006, at 5:55 PM, Roytman, Alex wrote:
Hello Mark,
There are two mechanisms in Kodo - jdbc-null-indicator for 1-1
embedded
and jdbc-container-meta for collections/maps. In general I was talking
about jdbc-container-meta one. The docs state:
" 6.2.3.7. jdbc-container-meta
Container metadata is used to record non-essential information about
collection and map fields. If this extension is set to true,
collections
and maps will be able to distinguish between the empty state and the
null state. If this extension is set to false or is unset, then it
will
not be possible for Kodo to differentiate between these two states. In
this situation, all collections and maps in persistent objects loaded
from the database will be non-null"
Almost exactly what I want and I was kind of surprised by the limited
implementation of the feature.
I can certainly file a JIRA request if you'd like me to.
I wonder if there is any chance to get some advice on implementing
it in
Kodo JDO 3.4?
Do you think it is reasonable to expect this feature in 4.1
release? Is
4.1 coming soon? Will it have solid JDO2 implementation?
Thank you
alex
-----Original Message-----
From: Marc Prud'hommeaux [mailto:[EMAIL PROTECTED] On
Behalf Of
Marc Prud'hommeaux
Sent: Thursday, October 05, 2006 8:19 PM
To: [email protected]
Subject: Re: Proposal: Optimizing empty collection fetch. Meta
Column in
ContainerFieldMappling
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
