View results here -> http://cruisecontrol.jboss.com/cc/buildresults/hibernate-sybase-testsuite?log=log20060601014348
BUILD TIMED OUTAnt Error Message: build timeoutDate of build: 06/01/2006 01:43:48Time to build:
Unit Tests: (0) Total Errors and Failures
After chatting with Emmanuel, here is a draft plan for a closer integration between Hibernate and Lucene for performing full text queries.
Hibernate annotations for Lucene helps keeping the lucene indexes up to date, but doesn't provide a query facility.
It also lacks converters that would for
All sounds cool ;)
I can see the advantage of "converters" which can put elements into
Lucence in a better/human manner.
The loading of objects from Lucene + "yet another QL" I'm a bit more
critical about.
Would it not be better to do the following:
1. Use whatever QL Lucene supports to ex
About the QL :
You're right, the goal isn't to provide yet another QL, and Lucene's one should be used.
I meant having a Criteria type of QL, like what Compass does :CompassQueryBuilder queryBuilder = session.createQueryBuilder();
CompassHits hits = queryBuilder.bool()
.addMust( queryBuil
On Jun 1, 2006, at 12:31 PM, Sylvain Vieujot wrote:
> CompassHits hits = queryBuilder.bool() .addMust( queryBuilder.term
> ("name", "jack") ) .addMustNot( queryBuilder.term("familyName",
> "london") ) .toQuery() .addSort("familyName",
> CompassQuery.SortPropertyType.STRING) .addSort("birthda
On Thu, 01 Jun 2006 12:45:49 +0200, Christian Bauer
<[EMAIL PROTECTED]> wrote:
>
> On Jun 1, 2006, at 12:31 PM, Sylvain Vieujot wrote:
>
>> CompassHits hits = queryBuilder.bool() .addMust( queryBuilder.term
>> ("name", "jack") ) .addMustNot( queryBuilder.term("familyName",
>> "london") ) .toQuer
> I meant having a Criteria type of QL, like what Compass
> does :CompassQueryBuilder queryBuilder = session.createQueryBuilder();
>
> CompassHits hits = queryBuilder.bool()
> .addMust( queryBuilder.term("name", "jack") )
> .addMustNot( queryBuilder.term("familyName", "london") )
> .toQ
Currently CacheProvider exposes a single method for Hibernate
to obtain a cache adapter (a Cache impl). However, there are numerous
ways in which Hibernate uses the second level cache all of which have slightly
different semantics. As of right now, Hibernate uses the second level
cache fo
> Additionally, we may want to split the Cache interface into separate
> interfaces also based on usage; this would only be intended to allow
> clearer definition of the capabilities allowed from each usage scenario.
sounds like a good thing, code-readability/maintainability wise.
>
> Another ni
Sure. Your provider could do whatever you wanted in terms of using XYZ
for data caches, ABC for query caches, and DEF for general caches...
Another one is an optimistic tree-cache for entity data caches, and a
pessimistic tree-cache for the others.
Etc...
-Original Message-
From: Max A
I had some additional discussions with Gavin on that yesterday. What we
should do first is:
- implement the Lucene update system as a 2nd level cache provider.
It's a much better approach to properly update Lucene indexes
- write / reuse a Criteria API to query the lucene indexes which
returns
On Thu, 01 Jun 2006 15:47:48 +0200, Emmanuel Bernard
<[EMAIL PROTECTED]> wrote:
> I had some additional discussions with Gavin on that yesterday. What we
> should do first is:
> - implement the Lucene update system as a 2nd level cache provider.
> It's a much better approach to properly update
12 matches
Mail list logo
