On 21 Jan 2014, at 15:50, Sanne Grinovero <sa...@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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
