[OGM] AssociationPersister.collectionPersister()
by Emmanuel Bernard
>From what I could look at, AssociationPersister.collectionPersister() + inverse() is only called in OgmCollectionPersister.updateInverseSideOfAssociationNavigation() and the owning side CollectionPersister is provided.
So to answer your question
> is the collection persister passed to AssociationPersister#collectionPersister() supposed to always be the one from the main side? or the one from the currently processed side of the association?
The OgmCollectionPersister only do things if it is on the main side (ie not an inverse collection). So only the persister from the main side is provided.
11 years, 10 months
Support for Elasticsearch in Hibernate OGM proposal
by Jiri Holusa
Hi everybody,
I'm Jirka Holusa and I work JDG QA (Infinispan) team, just for you to know, this email has nothing to do with JDG :)
Currently, I looking for a nice topic for a diploma thesis and I came across one. I worked with Elasticsearch in my bachelor thesis and I thought it would be nice to integrate it with Hibernate.
So I found Hibernate OGM and thought thaht I would like to develop the Elasticsearch module for Hibernate OGM. I talked to Emmanuel and Sanne and they pretty liked the idea, so they suggested to move the discussion here on dev list.
I would love to read all your suggestions/proposals/tip etc. The rough plan is to first implement the JPA API (therefor CRUD operations) and once this is finished, implement search capabilities via Hibernate Search API.
I looking forward to your replies.
Cheers,
Jirka
11 years, 10 months
Radio silence
by Hardy Ferentschik
Hi there,
A couple of months ago I started GPG signing my emails. As it turns out the hibernate-dev mailing list silently ignored/discarded all my emails since then.
As per configuration all emails with any type of attachment were ignored. Hence the two months radio silence of mine.
Some of you got also direct replies to the emails I replied to, so not all is lost. I still will resend some of my latest emails, since they are
responses to general discussions.
Sorry about that :-(
—Hardy
11 years, 11 months
Using raw vs. wildcard types
by Gunnar Morling
Hi,
every now and then I run into usages of raw types in our code bases:
* Class entityType (instead of Class<?>)
* Set querySpaces (instead of Set<String>)
...
I first thought that'd be left-overs from ancient times but apparently this
is also done in newly written code. I don't like it as in some cases it's
clearly a loss of information which requires investigation in surrounding
code to find out e.g. which types are put into a raw Set. In other cases
(e.g. Class) I prefer to use the wildcard type (Class<?>) as it avoids many
raw-type warnings in the IDE (which otherwise may obfuscate legitimate
warnings).
Is there any reason for using raw types in new code rather than full
generic or wildcard types?
Personally I try to fix existing usages of raw types and avoid to add new
ones if possible, but sometimes I can't (e.g. one cannot override a method
expecting a Class with a method expecting a Class<?>).
Thanks,
--Gunnar
11 years, 11 months
HSearch 5.0
by Marc Schipperheyn
Hi,
Is there any tentative idea on Hibernate Search 5.0 will come out? It just
feels like progress is extremely slow and when I look at JIRA I keep seeing
issues being added and fixed that seem extremely contextual (WildFly,
improve errorHandler, etc) and nothing to do with the ambition to deliver
the cool new features of Lucene 4 to the masses. I mean, I'm extremely
anxious to work with Lucene 4 like forever, because it brings so much to
the table and it will be great to have that power at your fingertips, but
of course, it would be even greater if that power is brought to the
Hibernate Search API.
Cheers,
Marc
11 years, 11 months
Re: [hibernate-dev] Redefining inheritance mapping, and why to follow same rules as ORM
by Thomas Kuhlmann
Please apologize me to reply to this discussion although I am not a
hibernate-developer.
I created issue "HSEARCH-1656", because I have some entities at
different points in my entity hierarchy (thus with different
super-classes), but all those entities (and only those) should be
indexed by hibernate-search. The have all the same fields to be indexed
(including embedded index) and the (not so small) index-configuration is
always the same.
Of course, I can solve this, be adding the necessary annotations to each
of those entities, but I do not like redundancy, so I had the idea of
using an interface there.
I really do not have any idea how much effort it is to implement such
feature. I just can say, it would be useful to me (and maybe to others ...).
If you send me some entry point to the code (e.g. a class or method) for
that topic I will take a look on the code for myself ... .
Thomas
> I am really really not in favor of handling annotations from interfaces.
> As you hints, it creates a *massively complex* set of rules on
> overridability and inconsistent usages.
> We might be able to solve them but how many months of work for what
> reward? I'd rather implement free-form entity and leave it open for
> someone to try that super duper max inheritance rule set of death.
> BTW ORM does not inherit annotations from interfaces.
>
> If you expect all subclasses to be provided to you by the system
> bootstrapping Hibernate Search we can offer subclass indexing.
> As you say, it will be working in ORM.
> I don't think it would in Infinispan as we don't know how to add to the
> same hierarchy but that's another story. We could do best effort (even
> though it's more unpredictable).
> Your idea of reusing Jandex won't quite fully work when people put their
> classes in different jars.
> And funnily enough, I don't think Hibernate ORM let's you save a
> subclass of an @Entity that is not itself annotated with @Entity (or
> itself have a subclass annotated @Entity).
>
> In short, not to annotations on interfaces.
> Neutral on indexing subclasses with the understanding that we are doing
> it as best effort but that will remain flaky. The ability to index the
> @IndexedEmbedded actual type instead of the static type seems to have
> more merit to me.
>
> Emmanuel
>
> On Thu 2014-08-21 14:50, Sanne Grinovero wrote:
>> First some context, we have issues open such as :
>> = HSEARCH-1656 - Recognize annotations from implemented interfaces
>> = HSEARCH-249 - Inheritance of annotations
>> = HSEARCH-1231 - Discuss if @Indexed annotation should not be
>> inherited by default
>>
>> I've always felt it odd that we would ignore subtypes for @Indexed
>> entities, but when mentioned I got excellent counter-arguments.
>> Nowadays though I've mostly forgotten why we don't, and I'm wondering
>> if those arguments still stand, especially as our position to issues
>> like:
>>
>> 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.
>>
>> 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.
>> b) I'm not sure anymore that we need that: in the ORM use case users
>> won't be allowed to run CRUD operations on unknown entities anyway, so
>> I think it's safe to assume that any entity passed to Search has been
>> known by ORM (and passed to us at bootstrap). Am I wrong?
>>
>> The question stands for non-ORM use cases, but for example Infinispan
>> Query needs to apply on-the-fly registration of new types as needed
>> already: not a new problem there.
>>
>> #2 Is HSEARCH-1656 a good idea?
>>
>> I find the idea fascinating, but we'd need to apply strict validations
>> against the usual problems of multiple inheritance. Many of our
>> class-level annotations do not allow repetitions and we'd need to
>> evaluate each of them to see if they would be valid if you "inherit"
>> multiple of them.
>> For example, multiple @ClassBridge annotations could result in a
>> composition, but things like @DocumentId shall not be repeated, and I
>> wonder if we should allow conflicting fieldname writes.
>>
>> Other annotations are supposed to represent a function (having a
>> unique answer), like @AnalyzerDiscriminator: currently we mandate to
>> have only one of them, which keeps things simple and understandable;
>> if I have multiple discriminators defined (one on each interface),
>> would you expect the function to be applied independently on the
>> @Field(s) defined by that interface?
>> As someone defining different (independent) interfaces I would expect
>> that, as I might not know about someone putting both (more) interfaces
>> on a single concrete implementation, and probably the other
>> annotations of each interface are expecting that specific
>> AnalyzerDiscriminator to be applied to them.
>>
>> #3 Are #1 and #2 unrelated?
>>
>> I suspect they are not, IMHO if we do inheritance of annotations,
>> inheriting them from interfaces is the next natural and consistent
>> step. Or not?
>> So it would be important to evaluate their link before committing on
>> either, as it seems both have consequences.
>>
>> #4 Any example of inconsistent experience for ORM users to handle our
>> inheritance "differently"?
>>
>> *differently* is a biased term though as it suggests some violation of
>> least surprise, but actually as a user myself and as I think suggested
>> by various other users as well, while the ORM rules are clear this
>> missing inheritance in Search seems to have been a surprise to many. I
>> suspect people understand the two things are quite different and we
>> should pick a consistent rule (like decide to reject HSEARCH-383 ?)
>>
>>
>> Thanks a lot for any feedback,
>> Sanne
>>
>>
>> https://hibernate.atlassian.net/browse/HSEARCH-1656
>> https://hibernate.atlassian.net/browse/HSEARCH-249
>> https://hibernate.atlassian.net/browse/HSEARCH-1231
>> https://hibernate.atlassian.net/browse/HSEARCH-383
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
11 years, 11 months
[Search] Redefining inheritance mapping, and why to follow same rules as ORM
by Sanne Grinovero
First some context, we have issues open such as :
= HSEARCH-1656 - Recognize annotations from implemented interfaces
= HSEARCH-249 - Inheritance of annotations
= HSEARCH-1231 - Discuss if @Indexed annotation should not be
inherited by default
I've always felt it odd that we would ignore subtypes for @Indexed
entities, but when mentioned I got excellent counter-arguments.
Nowadays though I've mostly forgotten why we don't, and I'm wondering
if those arguments still stand, especially as our position to issues
like:
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.
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.
b) I'm not sure anymore that we need that: in the ORM use case users
won't be allowed to run CRUD operations on unknown entities anyway, so
I think it's safe to assume that any entity passed to Search has been
known by ORM (and passed to us at bootstrap). Am I wrong?
The question stands for non-ORM use cases, but for example Infinispan
Query needs to apply on-the-fly registration of new types as needed
already: not a new problem there.
#2 Is HSEARCH-1656 a good idea?
I find the idea fascinating, but we'd need to apply strict validations
against the usual problems of multiple inheritance. Many of our
class-level annotations do not allow repetitions and we'd need to
evaluate each of them to see if they would be valid if you "inherit"
multiple of them.
For example, multiple @ClassBridge annotations could result in a
composition, but things like @DocumentId shall not be repeated, and I
wonder if we should allow conflicting fieldname writes.
Other annotations are supposed to represent a function (having a
unique answer), like @AnalyzerDiscriminator: currently we mandate to
have only one of them, which keeps things simple and understandable;
if I have multiple discriminators defined (one on each interface),
would you expect the function to be applied independently on the
@Field(s) defined by that interface?
As someone defining different (independent) interfaces I would expect
that, as I might not know about someone putting both (more) interfaces
on a single concrete implementation, and probably the other
annotations of each interface are expecting that specific
AnalyzerDiscriminator to be applied to them.
#3 Are #1 and #2 unrelated?
I suspect they are not, IMHO if we do inheritance of annotations,
inheriting them from interfaces is the next natural and consistent
step. Or not?
So it would be important to evaluate their link before committing on
either, as it seems both have consequences.
#4 Any example of inconsistent experience for ORM users to handle our
inheritance "differently"?
*differently* is a biased term though as it suggests some violation of
least surprise, but actually as a user myself and as I think suggested
by various other users as well, while the ORM rules are clear this
missing inheritance in Search seems to have been a surprise to many. I
suspect people understand the two things are quite different and we
should pick a consistent rule (like decide to reject HSEARCH-383 ?)
Thanks a lot for any feedback,
Sanne
https://hibernate.atlassian.net/browse/HSEARCH-1656
https://hibernate.atlassian.net/browse/HSEARCH-249
https://hibernate.atlassian.net/browse/HSEARCH-1231
https://hibernate.atlassian.net/browse/HSEARCH-383
11 years, 11 months
