-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 
Author Message
 Post subject: Alternative @DocumentId field / Slow ResultTransformer
PostPosted: Mon Aug 16, 2010 5:51 pm 
Newbie

Joined: Mon Aug 16, 2010 5:29 pm
Posts: 1
Hi,

im working with Hibernate 3.5.1 and Search 3.2.1 final. The most stuff works, but i've
the wrapping form lucene search to JPA/Entity beans is slow.

For a legacy-issue i have to use a composite key.

I found out, that the select is very slow. This is maybe an H2 (Database) issue.
Because Hibernate Search seems to "optimize" the selects operations:
SELECT .... From .... (Key1 = ? AND Key2 = ?) OR (Key1 = ? AND Key2) OR......

However, H2 does a tablescan and is much slower than single selects.

1.) Is there any changes to change this select (dialekt?)
1b.) Should i post this as H2-bug?

I try a work-a-round with an own document-id (without composite key). Since 3.2.1 @DocmentId
is optional. But it seems impossible to annotate an other field for this.

Here is my bean:
Code:
@Entity
@Table(name = "ARTIKEL")
@Indexed
@Analyzer(impl = GermanUmlaut2Analyzer.class)

public class Artikel {
   
   @Id
   @FieldBridge(impl = com.at.od.notlauf.model.domains.ArtikelPKBridge.class)
   ArtikelPK artikelPK;
        ...
   @Column(name = "LANGTEXT", length=102)
   @Field(index=Index.TOKENIZED, store=Store.NO)
   String langText;
   ...
   @DocumentId(name = "Docid")
   @Column(name = "DOC_ID", unique=true)
   int doc_id;


and here is the stacktrace:

Caused by: org.hibernate.annotations.common.AssertionFailure: Two document id assigned: artikelPK and Docid
at org.hibernate.search.engine.DocumentBuilderIndexedEntity.checkDocumentId(DocumentBuilderIndexedEntity.java:185)
at org.hibernate.search.engine.DocumentBuilderContainedEntity.initializeMemberLevelAnnotations(DocumentBuilderContainedEntity.java:226)
at org.hibernate.search.engine.DocumentBuilderContainedEntity.initializeClass(DocumentBuilderContainedEntity.java:173)
at org.hibernate.search.engine.DocumentBuilderContainedEntity.init(DocumentBuilderContainedEntity.java:133)
at org.hibernate.search.engine.DocumentBuilderIndexedEntity.init(DocumentBuilderIndexedEntity.java:156)
at org.hibernate.search.engine.DocumentBuilderContainedEntity.<init>(DocumentBuilderContainedEntity.java:119)
at org.hibernate.search.engine.DocumentBuilderIndexedEntity.<init>(DocumentBuilderIndexedEntity.java:148)
at org.hibernate.search.impl.SearchFactoryImpl.initDocumentBuilders(SearchFactoryImpl.java:519)
at org.hibernate.search.impl.SearchFactoryImpl.<init>(SearchFactoryImpl.java:171)
at org.hibernate.search.event.FullTextIndexEventListener.initialize(FullTextIndexEventListener.java:126)
at org.hibernate.event.EventListeners$1.processListener(EventListeners.java:198)
at org.hibernate.event.EventListeners.processListeners(EventListeners.java:181)
at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:194)
... 76 more

2.) Is is possible to to set an own documentid field?

/Robert


Top
 Profile  
 
 Post subject: Re: Alternative @DocumentId field / Slow ResultTransformer
PostPosted: Tue Aug 17, 2010 6:05 am 
Hibernate Team
Hibernate Team

Joined: Thu Apr 05, 2007 5:52 am
Posts: 1689
Location: Sweden
It should be possible. I think there is a bug. I created HSEARCH-574 for it.

--Hardy


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 2 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.