Chances are that if you need to use exactly the field name, using a
TwoWayStringBridge is what you need.
On Jun 16, 2008, at 04:20, Hardy Ferentschik wrote:
On Sun, 15 Jun 2008 18:22:22 +0200, Emmanuel Bernard <[EMAIL PROTECTED]
> wrote:
I am not sure if I like lazy field loading in the se
On Sun, 15 Jun 2008 18:22:22 +0200, Emmanuel Bernard
<[EMAIL PROTECTED]> wrote:
I am not sure if I like lazy field loading in the second case. The
proposed metadata to FieldBridge (FieldBridge.fieldNameStrategy()
EXACT, IN_NAMESPACE, NON_SAFE) seems very artificial. If we extend the
Field
On Jun 15, 2008, at 06:01, Hardy Ferentschik wrote:
Hi,
On Sun, 15 Jun 2008 10:24:55 +0200, Sanne Grinovero <[EMAIL PROTECTED]
> wrote:
what is your goal? performance?
Here is the full story. While writing Hibernate Search in Action I
explained how a database lookup by id is not funda
On Jun 15, 2008, at 04:24, Sanne Grinovero wrote:
what is your goal? performance?
Performance, memory consumption, reduce the gap between entity loading
and projection from a perf point of view (assuming projection loads
the same amount of data).
from the code I guess you don't inte
Sorry, that was bogus. Not sure what I was thinking. I should have looked
at the code first. Of course we need the bridges in the projection case
and for loading managed objects we just need the id.
--Hardy
On Sun, 15 Jun 2008 12:01:10 +0200, Hardy Ferentschik
<[EMAIL PROTECTED]> wrote:
Hi,
On Sun, 15 Jun 2008 10:24:55 +0200, Sanne Grinovero
<[EMAIL PROTECTED]> wrote:
what is your goal? performance?
Yeah, what's the actual goal? If the goal is performance have to compared
the performance of the original
solution with this 'simple' patch? I think to justify complicating
what is your goal? performance?
from the code I guess you don't intend to support something like
setProjection( FullTextQuery.DOCUMENT, "lastname" );
as you skip fieldnames processing when you hit DOCUMENT;
I agree with you it would be a bit stupid, but someone could want
to do that for some pur
