Actually this is not exactly the scenario here...
This is the whole structure:
@Entity
@Indexed
@Analyzer(impl = org.apache.lucene.analysis.standard.StandardAnalyzer.class)
public class A {
@Id
@DocumentId
private String trans_id;
@OneToMany
@JoinColumn(name = "trans_id")
@IndexedEmbedded
private Set<B> B_obj;
}
@Entity
@Indexed
@Analyzer(impl = org.apache.lucene.analysis.standard.StandardAnalyzer.class)
public class B {
@Id
@EmbeddedId
@FieldBridge(impl=com.att.ssam.txtsearch.utils.Ssam_trans_dtl_keyBridge.class)
@Field(index=Index.YES, analyze=Analyze.YES, store=Store.YES)
private C transKey;
public C getTransKey() {
return transKey;
}
}
@Embeddable
@Indexed
@Analyzer(impl = org.apache.lucene.analysis.standard.StandardAnalyzer.class)
public class C implements Serializable {
private static final long serialVersionUID = 1L;
private String trans_id;
private Timestamp msg_date;
C() {}
}
as you can see from above, my C class is being used as a composite key in class B, and in class B, it is getting stored as an index through :
Quote:
@Field(index=Index.YES, analyze=Analyze.YES, store=Store.YES)
private C transKey;
So there is no such multiple mapping scenario here..
Which is why I asked this question:
Quote:
Hibernate Search will implicitly create a field for the id property (as marked via @Id or @Documentid), no need to explicitly configure it via @Field.
Is this change specific to jpa 2.1 or so?
Please can you clarify my doubt... Now I am getting totally confused...
Also to mention:Quote:
Hibernate Search will implicitly create a field for the id property (as marked via @Id or @Documentid), no need to explicitly configure it via @Field.
If it will implicitly create an index or we can say field for the prop, then will it work with the default settings of @field annotation? i.e index=Index.YES, analyze=Analyze.YES and store=Store.NO are the default values
but i want :
index=Index.YES, analyze=Analyze.YES, store=Store.YES
these settings, so will it be handling it implicitly?
Login
FAQ
Search
