Created branch 5.5 for Hibernate Search
by Sanne Grinovero
Hi all,
I just created a 5.5 branch on github for Hibernate Search, to
backport (so far) one issue which you all had flagged as "fixed for
5.5.1" on JIRA: please always make sure the state of JIRA tracks the
repository state accurately.
Thanks,
Sanne
10 years, 9 months
AttributeConverter and internally mutable domain types
by Steve Ebersole
Reference https://hibernate.atlassian.net/browse/HHH-10111
This comes down to the idea of a Type's mutability : can the thing's
internal state be changed? We use this for all kinds of optimizations. If
the internal state is not mutable, we know that "making a deep copy", for
example, is a simple matter of just returning the original. It also
affects how we dirty check it, how we (2nd level) cache it, etc.
So far we have assumed that types mapped using AttributeConverters are
immutable. However, this Jira is an example of where that breaks down.
I think for now we will have to assume that the AttributeConverter entity
type is mutable and build an appropriate MutabilityPlan. Moving forward I
think we should consider a means to allow developers
using AttributeConverter along with immutable state (which seems to be the
majority case) the option to somehow indicate that the converted-to type is
immutable which allows us to apply the more efficient plan. Thoughts on
the best way to achieve this latter part? I am initially thinking an
optional contract for the AttributeConverter impl itself to implement:
@Converter
class MyAttributeConverter
implements AttributeConverter<Name,String>,
HibernateAttributeConverter {
// normal AttributeConverter methods
/**
* HibernateAttributeConverter
*/
@Override
public boolean isMutable() {
return true;
}
}
Another option is to develop some annotations that are applied to the
AttributeConverter impl (much like the javax.persistence.Converter itself):
@Converter
@org.hibernate.annotations.MutableConvertedState(true|false)
class MyAttributeConverter implements AttributeConverter<Name,String> {
// normal AttributeConverter methods
}
10 years, 10 months
[Search] Something fishy with sort by id
by Guillaume Smet
Hi,
After the upgrade to Search 5.5 (I think we skipped 5.4 on this app), I
have a weird behavior when I sort by id.
My id is a Long just indexed with @DocumentId:
@Id
@DocumentId
private Long id;
and my sort is defined like this:
fullTextQuery.setSort(new Sort(new SortField("id", SortField.Type.LONG,
true)));
Everything was reindexed.
It used to work before. Is this something expected?
--
Guillaume
10 years, 10 months
SQM interpretation in my antlr-4-poc repo
by Steve Ebersole
Just a heads up that I finally got enough traction in this work towards
building a "SQL AST" to warrant a push upstream.
The majority of time has been trying to think through the best tree
structure for modeling from clauses especially in regards to
entity/collection persisters that map across multiple tables. So that is
where most of my work so far has gone. So far I have only worked through
handling entity persisters. You can see this contract
in org.hibernate.sql.orm.internal.mapping.ImprovedEntityPersister (which I
ultimately expect to augment the upstream EntityPersister contract with).
There are also some tests illustrating the structure that gets created for
various scenarios. So far I have only written tests for
SingleTableEntityPersister (which covers both no inheritance and
discriminator inheritance) with and without secondary tables. I will work
on expanding the covered scenarios as I have time during continued 5.0.2
and 5.1 development.
For those interested in taking a peek, the tree structure itself is defined
within the org.hibernate.sql.ast.from package. Be sure to see its
package-info for a high-level overview.
The tests are in the org.hibernate.sql.orm.internal.mapping test package.
The next steps (after filling out the tested scenarios) is to start work on
resolving AttributeReferences from the SQM using
the TableSpecificationGroup as a means to resolve the specific table
aliases needed for each column. After that, building the rest of the tree
ought to be pretty straight forward.
The other major task is to still account for "Dialect variance" (join
support, casting, etc).
10 years, 10 months
A few questions about Search 5.5.0
by Guillaume Smet
Hi,
I upgraded our framework to 5.5.0 and I have a few questions about it.
==
First, I had to remove the existing indexes otherwise I had exceptions
about version of the index. Is this expected? As far as I remember, it's
been a long time since we had to remove the indexes after an upgrade.
Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
version is not supported (resource
BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
-11 (needs to be between 1071082519 and 1071082519). This version of
Lucene only supports indexes created with release 4.0 and later.
Maybe it should be integrated in the blog post that one might need to
clean up indexes if they come from before the switch to Lucene 4?
==
Second, I have warnings like that in my logs:
HSEARCH000289: Requested sort field(s) company.nameSort, nameSort are not
configured for entity type
fr.openwide.helios.core.business.contract.model.HeliosContract mapped to
index fr.openwide.helios.core.business.contract.model.HeliosContract, thus
an uninverting reader must be created. You should declare the missing sort
fields using @SortField.
Shouldn't it be @Sort*able*Field?
==
And finally, since recently, it's necessary to sort dates using
SortField.Type.LONG instead of SortField.Type.STRING. I haven't found this
information in the blog posts of any releases. Or did I miss something?
--
Guillaume
10 years, 10 months
