openjpa-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kevin Sutter" <kwsut...@gmail.com>
Subject Re: svn commit: r510281 - in /incubator/openjpa/trunk: openjpa-jdbc/src/main/java/org/apache/openjpa/jdbc/sql/ openjpa-kernel/src/main/java/org/apache/openjpa/kernel/ openjpa-persistence/src/main/java/org/apache/openjpa/persistence/
Date Tue, 27 Feb 2007 18:43:38 GMT
I have backed out the original changes via svn revision 512327 -- just did
it this morning.  Dave will create a JIRA report for this optimization so
that we can work through the issues and then we'll integrate a new set of
changes.

Kevin

On 2/22/07, Abe White <awhite@bea.com> wrote:
>
> > 3. OpenJPA does support a means of passing Oracle hints along
> > through to
> > the DBDictionary. Should we be trying to reuse some of the
> > capabilities
> > here?
>
> +1
>
> > 4. In the following snippets, I'd rather if we used 'Integer.valueOf
> > (1)'
> > or, better yet, a symbolic constant, instead of creating new
> > integer all
> > the time.
> >
> >> +        fetch.setHint("openjpa.hint.optimize", new Integer(1));
> >
> >> +            _query.getFetchConfiguration().
> >> +                    setHint("openjpa.hint.optimize", new Integer(1));
>
> Use serp.util.Numbers.valueOf(x).
> But actually I think both of these calls have to be more thoroughly
> re-thought.  The FetchConfiguration is around for the life of the
> Broker/Query, and you're setting a hint on it that only applies to
> the very next call.  What about all the other uses of the Broker or
> possible other executions of the Query?
>
> > 5. I don't like the name 'openjpa.hint.optimize', as it's a bit
> > ambiguous as to what's being optimized. I don't really know what
> > 'optimize for' does, so I'm just guessing here, but how about
> > 'openjpa.ExpectedRecordCount'?
>
> +1  But should be openjpa.hint.XXX -- see OracleDictionary.SELECT_HINT.
>
> I think we should move all this to a
> SelectExecutor.ExpectedResultCount property.  It could replace the
> current Union.isSingleResult property.  The user can set an expected
> result count via the Query hint API, and it will get set into the
> Select.  In cases where a query range is set the property will return
> the max - min of the range.  And in cases where we know there's only
> one result like find() calls (actually JDBCStoreManager.load) we can
> use the property directly internally.  The DBDictionary can then ask
> the Select for the expected count and do what it wants with it when
> creating the SQL.
>
>
> _______________________________________________________________________
> 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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message