[hibernate-dev] Redefining inheritance mapping, and why to follow same rules as ORM

[Hardy Ferentschik]

On 21 Jan 2014, at 15:50, Sanne Grinovero <sanne at hibernate.org> wrote:

> HSEARCH-383 -  Hibernate Search does not respect the @AccessType
> annotation in respect to @Id fields.
> 
> is that we don't necessarily follow the same rules as Hibernate ORM.
> Also we're currently aiming at more flexible models, not least as
> needed by protobuf encoded models like in Infinispan Query, but we
> want of course to be consistent for users of Hibernate ORM.

I would like to stay away from trying to understand access type rules in Search.
It is not the job of Search to understand JPA behaviour. IMO the fact that we use
@Id in case there is not specific @DocumentId is just a nice little feature. If you
start using @Id mixed with @AccesType and things do not work as expected anymore,
then you should just switch to a explicit @DocumentId

> So questions:
> 
> #1 Why don't we assume subclasses of an @Indexed entity is indexed as well?
> 
> A comment in HSEARCH-1231 points out that this would need classpath
> scanning, but
> a) If it makes sense we should JFDI, or explore Jandex superpowers to help.

I think we can/should consider sub classes as well. However, I would indeed
first switch to Jandex. I don’t see this issue as a high priority and working things
out in the current code will take time which will be wasted once we switch to
Jandex. There the processing would work a bit differently and in fact easier.

> #2 Is HSEARCH-1656 a good idea?

Again, I would probably hold of on this for now.

—Hardy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/20140822/debf069f/attachment.bin