Configuration, deprecation and 4.x plans
by Steve Ebersole
This morning on IRC we discussed the fact that Configuration is still
marked as deprecated in the 4.0 code base and whether we should revert
that. This ties in with post-4.0 plans so I think its best to outline
that here. The plan is :
1) Revert the deprecation on Configuration and Ejb3Configuration for 4.0.
2) Plan on finishing up the metamodel code for 4.1 at which time we will
again deprecate these 2, scheduled for removal in 5.0
3) Prosper!
Also I'd like to see 5.0 come sooner rather than later after 4.1
--
steve(a)hibernate.org
http://hibernate.org
14 years, 1 month
[Search] 3.4.1: HSEARCH-776 fix causes index out of bound exception
by Elmer van Chastelet
Hi again,
I just upgraded to from HS 3.4.0 to 3.4.1.
When using range faceting, I get this exception:
--------------------
exception message: toIndex = 3
java.lang.IndexOutOfBoundsException: toIndex = 3
at java.util.ArrayList.subListRangeCheck(ArrayList.java:885)
at java.util.ArrayList.subList(ArrayList.java:877)
at org.hibernate.search.query.collector.FacetCollector.createSortedFacetList(FacetCollector.java:139)
at org.hibernate.search.query.collector.FacetCollector.getFacetList(FacetCollector.java:128)
at org.hibernate.search.query.engine.impl.QueryHits.updateTopDocs(QueryHits.java:236)
at org.hibernate.search.query.engine.impl.QueryHits.<init>(QueryHits.java:127)
at org.hibernate.search.query.engine.impl.HSQueryImpl.getQueryHits(HSQueryImpl.java:419)
at org.hibernate.search.query.engine.impl.HSQueryImpl.queryDocumentExtractor(HSQueryImpl.java:275)
at org.hibernate.search.query.engine.impl.FacetManagerImpl.getFacets(FacetManagerImpl.java:111)
at org.webdsl.search.AbstractEntitySearcher.getFacets(AbstractEntitySearcher.java:520)
http://pastebin.com/43C2c3Ld
---------------------
Probably it is introduced by the fix for https://hibernate.onjira.com/browse/HSEARCH-776
The fix in 3.4.1 is different from my fix which I've attached in HSEARCH-776. When I replace the FacetCollector.java in the 3.4.1 source with mine, I don't get this exception.
We don't use the query builder, but construct the faceting request directly from our syntax:
--------------------
FacetingRequestImpl rfr = new RangeFacetRequest<T>( facetName(field), field, facetRangeList, documentBuilder );
rfr.setSort( FacetSortOrder.RANGE_DEFINITION_ODER );
rfr.setIncludeZeroCounts( false );
rfr.setMaxNumberOfFacets( facetRangeList.size() );
http://pastebin.com/j2kg9wxt
--------------------
I think it has something to do with the facetRequest.getMaxNumberOfFacets() and IncludeZeroCounts.
New Jira issue, reopen, ... ?
Elmer
14 years, 1 month
SuggestiMate
by Hardy Ferentschik
hi,
I have a vague feeling that we had this question before, but could we have
SuggestiMate (see the JBoss issue tracker) on our Jira instance as well?
--Hardy
14 years, 1 month
On @OneToOne(optional=true) and @PrimaryKeyJoinColumn
by Emmanuel Bernard
There is a distinction between optional=true and @NotFound
I have had a few discussions with Gail on https://hibernate.onjira.com/browse/HHH-4982 and https://hibernate.onjira.com/browse/ANN-725
Don't spend too much time on these issue reports, they are very confusing.
The question boils down to whether or not @OneToOne(optional=true) @PrimaryKeyJoinColumn is legal what the implication is on FK constraint generation and inner vs outer join use to load the object.
Let's take the simple @ManyToOne example
@ManyToOne(optional=true) @JoinColumn(name="profile_fk")
@NotFound(IGNORE)
Profile getProfile() { ... };
optional = true means that there may or may not be a Profile ie that profile_fk is nullable
@NotFound(IGNORE) means that if profile_fk points to a profile that is not present in the Profile table (say the fk = "emmanuel" and there is no profile with "emmanuel" as a PK).
@NotFound(IGNORE) is here to make Hibernate work on *broken* databases where the DBA was smart enough to decide FK constraints are useless.
This one is easy.
Now for true one to one these two concepts mix in
@Entity
class User {
@Id String username;
@OneToOne(optional=true) @PrimaryKeyJoinColumn
Profile getProfile() { ... };
}
In this case, a User "emmanuel" has a profile whose primary key is "emmanuel": the PK of User is also a foreign key pointing to profile.
Now it's perfectly reasonable to imagine that a User has no Profile in which case, the User PK which is also the FK to profile would point to a non existent entry in Profile. That would mean that we cannot enforce the foreign key constraint.
I think that for generated ids (via "foreign" or via derived identity), we cannot have optional values. That would defeat the purpose of the generator. In these case we should ignore optional=true (and log a warning).
For ids that are not generated, I'm torn. I see the use case above as a decent use case for which we would not do to outer joins instead of inner joins.
I think that the Hibernate engine reacts properly with the following mapping
@Entity
class User {
@Id String username;
@OneToOne(optional=true) @PrimaryKeyJoinColumn
@NotFound(IGNORE)
Profile getProfile() { ... };
}
so we could make @NotFound(IGNORE) implicit when @OneToOne(optional=true) @PrimaryKeyJoinColumn is found.
Emmanuel
14 years, 1 month
JPA 2 spec excerpts about @PrimaryKeyJoinColumn and derived identities
by Gail Badner
I'm sending these excerpts separately, rather than cluttering up Emmanuel's thread.
Regards,
Gail
11.1.40 PrimaryKeyJoinColumn Annotation
The PrimaryKeyJoinColumn annotation specifies a primary key column that is used as a foreign key to join to another table.
The PrimaryKeyJoinColumn annotation is used to join the primary table of an entity subclass in the JOINED mapping strategy to the primary table of its superclass; it is used within a SecondaryTable annotation to join a secondary table to a primary table; and it may be used in a OneToOne mapping in which the primary key of the referencing entity is used as a foreign key to the referenced entity[108].
Footnote [108]:
The derived id mechanisms described in section 2.4.1.1 are now to be preferred over PrimaryKeyJoinColumn for the OneToOne mapping case.
2.4.1 Primary Keys Corresponding to Derived Identities
The identity of an entity may be derived from the identity of another entity (the "parent" entity) when the former entity (the "dependent" entity) is the owner of a many-to-one or one-to-one relationship to the parent entity and a foreign key maps the relationship from dependent to parent.
If a many-to-one or one-to-one entity relationship corresponds to a primary key attribute, the entity containing this relationship cannot be persisted without the relationship having been assigned an entity since the identity of the entity containing the relationship is derived from the referenced entity.[12]
14 years, 1 month
[Search] supporting DISTINCT (or similar) for values
by Sanne Grinovero
This was asked some times, and today a new interesting use case was
proposed on the forums:
https://forum.hibernate.org/viewtopic.php?f=9&t=1012360
I usually tell the whole story "distinct is not fit for fulltext...
use the relational queries" but since it's often requested (on
Infinispan Query too) and I just realized that in fact we could
implement it as the needed information is in the index, and we could
efficiently extract it and wrap in a nice and easy API.
Shall I open a JIRA for this? Likely for 4.1 I would say, for now I'm
just collecting opinion if we should support this, and if somebody has
an idea of how such an API should look like.
Sanne
14 years, 1 month
Re: [hibernate-dev] Releasing 3.4.1 ?
by Emmanuel Bernard
Sure, you can trigger the release. I agree with your suggestions on issue resolution except that I would not bump major (nor minor) version numbers for the dependencies. Only micro.
For example, Infinispan 5 has broken compatibility on us several times during the CR cycle. I would not dare to ask users to switch on a maintenance release.
Emmanuel
On 22 août 2011, at 23:52, Sanne Grinovero wrote:
> The wannabe 3.4.1 branch is quite interesting, already 15 issues
> solved and just 3 pending:
>
> https://hibernate.onjira.com/secure/IssueNavigator.jspa?reset=true&mode=h...
>
> I've been asked again if we have plans for a release.
>
> Looking at the three pending issues:
>
> HSEARCH-841 : Imo it can be postponed, unless with the last comments
> and proposed patch someone is able to make a test
> HSEARCH-820 : easy
> HSEARCH-811 : easy but I won't look at it unless we release soon (it's
> about upgrading dependencies; I guess we mean minor versions only)
>
> I would add one, depending on your opinion:
>
> - Infinispan 5.0
>
> When 3.4.0.Final I had been tempted to upgrade Infinispan to 5.0 as
> the amount of bugfixes in 5 over 4.2 is *huge* but it wasn't final yet
> so Emmanuel suggested we shouldn't throw betas to people (In fact I
> had upgraded and then we reverted it).
>
> Infinispan 5.0.0.FINAL is released now.. makes sense to add a mayor
> dependency upgrade in this case?
> I see people starting to try it out on (both) forums, and having much
> trouble with stuff which was long fixed during the preparations for
> Infinispan 5.
>
> If you agree with it I can take care of these issues and release it in
> evening hours during this week.
>
> Cheers,
> Sanne
14 years, 1 month
