2:48 p.m.
I have been adding new features on Hibernate Search recently (SVN)
Projection
The ability to project some fields the index only avoiding the
database roundtrip.
fullTextQuery.setProjection("id", "summary",
"author.name").list();
will return a List<Object[]> like the regular HQL projection
the fieldbridge has to be two way (all built-in are) and the
projected fields have to be Store.YES or Store.COMPRESS
It's useful when you want to display a small subset of the data,
don't want managed objects, are OK to have a bigger index and if the
performance of the non projection strategy doesn't meet your
requirements (arguably uncommon);
A few questions:
Currently fields Store.NO or where the fieldbridge is one way are
ignored and return null.
The idea behind that is to be able to project across multiple
entities / index. Not sure if it's a useful feature.
What do you think of the API? I thought about reusing the Criteria
Projection API but it's too tight to SQL
If people could give it a try...
Object load by query rather than batch-size
When querying a given entity type ( eg ftSession.createFullTextQuery
(luceneQuery, Book.class) ). HSearch now use a query with an in
clause, reducing the number of database roundtrip especially if you
don't set up @BatchSize on the entity
Custom query to load objects
You can define the Criteria query that will be use to load the
matching objects of a lucene query.
This is especially useful when an object graph (rather than an
object) is expected: you can refine the fetchMode.
result = s.createFullTextQuery( query ).setCriteriaQuery(
s.createCriteria( Book.class ).setFetchMode( "authors",
FetchMode.JOIN )
).list();
will load the matching books and the associated authors.
Sorting (thanks to Hardy)
fullTextQuery.setSort(luceneSort).list();
Remember that a sorted field must not be tokenized
I will add the ability to index a property multiple times to cope
with that.
Expose resultSize()
ie the total number of result regardless of the pagination
fullTextQuery.setMaxResult(20)resultSize() == 3000
A better name is more than welcome.
@IndexedEmbedded for collections
What was available for regular objects is now possible for collections
I am fairly happy with the feature set for beta2, I will probably
close a couple of issues and release beta2 (round end of next week,
no guaranty though).
Feedback on those features are welcome esp projection, custom query
and their APIs
Emmanuel
12:41 a.m.
Projection
The ability to project some fields the index only avoiding the
database roundtrip.
fullTextQuery.setProjection("id", "summary",
"author.name").list();
will return a List<Object[]> like the regular HQL projection
the fieldbridge has to be two way (all built-in are) and the
projected fields have to be Store.YES or Store.COMPRESS
What about .setCachedProjection or .setIndexedProjection to clearly signal
it is not a "real" projection ?
It's useful when you want to display a small subset of the data,
don't want managed objects, are OK to have a bigger index and if the
performance of the non projection strategy doesn't meet your
requirements (arguably uncommon);
A few questions:
Currently fields Store.NO or where the fieldbridge is one way are
ignored and return null.
The idea behind that is to be able to project across multiple
entities / index. Not sure if it's a useful feature.
Shouldn't this result in an error ?! if the property is not actually
"mapped"
shouldn't it fail ?
Custom query to load objects
You can define the Criteria query that will be use to load the
matching objects of a lucene query.
This is especially useful when an object graph (rather than an
object) is expected: you can refine the fetchMode.
result = s.createFullTextQuery( query ).setCriteriaQuery(
s.createCriteria( Book.class ).setFetchMode( "authors",
FetchMode.JOIN )
).list();
will load the matching books and the associated authors.
What happens if the query and the criteria are totally unrelated ? And how
are the link
done between "query" and the Criteria ? you just add an in clause on the
"id" property "blindly" ?
Expose resultSize()
ie the total number of result regardless of the pagination
fullTextQuery.setMaxResult(20)resultSize() == 3000
A better name is more than welcome.
getResultSize() ? :)
Feedback on those features are welcome esp projection, custom query
and their APIs
looks cool.
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
6:09 p.m.
On 18 mai 07, at 01:41, Max Rydahl Andersen wrote:
> Projection
What about .setCachedProjection or .setIndexedProjection to
clearly signal
it is not a "real" projection ?
But it *is* a real projection, just not from the database :-) The
data is the same though
The API is in FullTextQuery.setProjection()
Do we need the redundancy?
> Currently fields Store.NO or where the fieldbridge is one way are
> ignored and return null.
> The idea behind that is to be able to project across multiple
> entities / index. Not sure if it's a useful feature.
Shouldn't this result in an error ?! if the property is not
actually "mapped"
shouldn't it fail ?
I couldn't make my mind.
My choice comes from the fact that Lucene is a totally unstructured
data container.
For eg if you query
title:Hibernate summary:Rock
and if the documents don't have the summary field, it's silently
ignored by lucene
It's kinda cool if you want to retrieve let's say Dvd and Book, some
fields are shared and some are specific
But I will align with the majority here and better be strict first
and relax later.
> Custom query to load objects
> You can define the Criteria query that will be use to load the
> matching objects of a lucene query.
> This is especially useful when an object graph (rather than an
> object) is expected: you can refine the fetchMode.
>
> result = s.createFullTextQuery( query ).setCriteriaQuery(
> s.createCriteria( Book.class ).setFetchMode( "authors",
> FetchMode.JOIN )
> ).list();
>
> will load the matching books and the associated authors.
What happens if the query and the criteria are totally unrelated ?
And how are the link
done between "query" and the Criteria ? you just add an in clause
on the "id" property "blindly" ?
It can't be, I read the Criteria entity root to filter the
unstructured query
Yes I add an in clause (several actually, thanks Oracle) to the
property marked as @DocumentId
11:06 a.m.
>> Projection
>
> What about .setCachedProjection or .setIndexedProjection to clearly
> signal
> it is not a "real" projection ?
But it *is* a real projection, just not from the database :-) The data
is the same though
The API is in FullTextQuery.setProjection()
Do we need the redundancy?
It's just that your other query results are "real" data from the db,
unless you
use setProjection() where it then starts returning purely indexed/cached
data instead.
Compare it to how we do 'cached' queries in "normal" hibernate api:
createFullTextQuery("blah blah").setProjection(...).list();
vs.
createQuery("blah blah").setCachable(true).list();
The latter is "obvious", the former is not IMO. It looks more like
Criteria API's
projection which again is assumed to return a consistent result instead of
a possible
cached/out-of-sync result.
>> Currently fields Store.NO or where the fieldbridge is one way
are
>> ignored and return null.
>> The idea behind that is to be able to project across multiple
>> entities / index. Not sure if it's a useful feature.
>
> Shouldn't this result in an error ?! if the property is not actually
> "mapped"
> shouldn't it fail ?
I couldn't make my mind.
My choice comes from the fact that Lucene is a totally unstructured data
container.
For eg if you query
title:Hibernate summary:Rock
and if the documents don't have the summary field, it's silently ignored
by lucene
It's kinda cool if you want to retrieve let's say Dvd and Book, some
fields are shared and some are specific
Well can't you just verify if the field exists against the possible result
domain space (in
this case Dvd and Book) ? If the field does not exist at all it is
definitly an error.
>> Custom query to load objects
>> You can define the Criteria query that will be use to load the
>> matching objects of a lucene query.
>> This is especially useful when an object graph (rather than an
>> object) is expected: you can refine the fetchMode.
>>
>> result = s.createFullTextQuery( query ).setCriteriaQuery(
>> s.createCriteria( Book.class ).setFetchMode( "authors",
>> FetchMode.JOIN )
>> ).list();
>>
>> will load the matching books and the associated authors.
>
> What happens if the query and the criteria are totally unrelated ? And
> how are the link
> done between "query" and the Criteria ? you just add an in clause on
> the "id" property "blindly" ?
It can't be, I read the Criteria entity root to filter the unstructured
query
Yes I add an in clause (several actually, thanks Oracle) to the property
marked as @DocumentId
Ok - so it will just return an empty result if there is a mismatch.
--
--
Max Rydahl Andersen
callto://max.rydahl.andersen
Hibernate
max(a)hibernate.org
http://hibernate.org
JBoss a division of Red Hat
max.andersen(a)jboss.com
3:15 p.m.
Hi,
Projection
The ability to project some fields the index only avoiding the
database roundtrip.
fullTextQuery.setProjection("id", "summary",
"author.name").list();
will return a List<Object[]> like the regular HQL projection
the fieldbridge has to be two way (all built-in are) and the
projected fields have to be Store.YES or Store.COMPRESS
Looks good to me. It is a shame so that you have to specify the index
field names explicitly as strings.
I wonder if there could be another way? On the one hand you are able to
index a field just via annoation,
not caring what the lucene field name will be, on the other hand you have
to use the field names in the projection.
Unfortunately, I haven't used projections before so I have to understand
the code first.
My main question right now - what type of objects are returned from the
query? Partly populated objects of the
managed classes or some other sort of objects?
Nevertheless, I will try it right away. I was basically looking for a
solution which would not go all the way to the
database.
A few questions:
Currently fields Store.NO or where the fieldbridge is one way are
ignored and return null.
The idea behind that is to be able to project across multiple
entities / index. Not sure if it's a useful feature.
I guess I would expect an
error if I include a field to be projected, but
it is not stored in the index.
Expose resultSize()
ie the total number of result regardless of the pagination
fullTextQuery.setMaxResult(20)resultSize() == 3000
A better name is more than welcome.
I would also opt for getResultSize()
I am fairly happy with the feature set for beta2, I will probably
close a couple of issues and release beta2 (round end of next week,
no guaranty though).
That would be great. I will be testing the new features within
the
application we are currently developing.
Cheers,
Hardy
6:16 p.m.
> Projection
> The ability to project some fields the index only avoiding the
> database roundtrip.
> fullTextQuery.setProjection("id", "summary",
"author.name").list();
> will return a List<Object[]> like the regular HQL projection
> the fieldbridge has to be two way (all built-in are) and the
> projected fields have to be Store.YES or Store.COMPRESS
Looks good to me. It is a shame so that you have to specify the
index field names explicitly as strings.
I wonder if there could be another way? On the one hand you are
able to index a field just via annoation,
not caring what the lucene field name will be, on the other hand
you have to use the field names in the projection.
Unfortunately, I haven't used projections before so I have to
understand the code first.
My main question right now - what type of objects are returned from
the query? Partly populated objects of the
managed classes or some other sort of objects?
Nevertheless, I will try it right away. I was basically looking for
a solution which would not go all the way to the
database.
What is retrieved is an Object[], it's a true projection, like a HQL
one, I will add the resultTransformer feature later on though, so the
Object[] can be converted.
You assume that someone will want to retrieve all the stored fields
and that HSearch can guess the list of fields. But it may very well
be a subset of the stored fields depending on the query, hence the
actual list of fields. Then if I return an Object[], with all fields,
the question of the ordering pops up.
My idea was to keep it consistent with what users do today in Hibernate.
> A few questions:
> Currently fields Store.NO or where the fieldbridge is one way are
> ignored and return null.
> The idea behind that is to be able to project across multiple
> entities / index. Not sure if it's a useful feature.
I guess I would expect an error if I include a field to be
projected, but it is not stored in the index.
OK I will change that
> Expose resultSize()
> ie the total number of result regardless of the pagination
> fullTextQuery.setMaxResult(20)resultSize() == 3000
> A better name is more than welcome.
I would also opt for getResultSize()
OK
6433
days inactive
6435
days old
5 comments
3 participants
participants (3)
-
Emmanuel Bernard -
Hardy Ferentschik -
Max Rydahl Andersen