HSEARCH-471 Ability to selectively index an entity based on its state
by Emmanuel Bernard
Maybe it's time to revive this one since we have started to go down the rabbit hole with indexing only when dirty searched properties are present.
Begin forwarded message:
> From: "lantz moore (JIRA)" <noreply(a)atlassian.com>
> Date: 14 janvier 2011 01:52:05 HNEC
> To: emmanuel(a)hibernate.org
> Subject: [Hibernate-JIRA] Commented: (HSEARCH-471) Ability to selectively index an entity based on its state
>
>
> Issue (View Online)
> Key: HSEARCH-471
> Issue Type: New Feature
> Status: Open
> Priority: Minor
> Assignee: Unassigned
> Reporter: Dobes Vandermeer
>
> Operations
> View all
> View comments
> View history
> Ability to selectively index an entity based on its state
> Updated: 13/Jan/11 6:51 PM Created: 16/Mar/10 12:10 PM
>
> The following comment has been added to this issue: [ Permalink ]
> Author: lantz moore
> Date: 13/Jan/11 6:51 PM
> Comment:
> up until some recent restructuring of FullTextIndexEventListener and EventSourceTransactionContext i was able to implement something like this very easily.
>
> first, my use case: we have a few objects that are expensive to index but are modified "a lot". we only want them indexed at a few well defined transitions: initial creation and when certain members are modified. otherwise, we don't need them to be reindexed.
>
> to solve this issue with earlier versions of hib-search, we extended FullTextIndexEventListener and overrode processWork. we map classes to MVEL expressions and use the MVEL expressions to evaluate whether or not to index the entity.
>
> we define the FullTextIndexEventListener in spring and configure it like:
>
> <bean id="fullTextIndexer" class="com.example.dao.hibernate.FullTextIndexEventListener">
> <property name="entityChecks">
> <map>
> <entry key="com.example.model.RetailTransaction">
> <value>
> if (event is org.hibernate.event.PostUpdateEvent) { return (oldState.suspended != newState.suspended || entity.getTransactionState().name() != "PENDING") }
> return true;
> </value>
> </entry>
> </map>
> </property>
> </bean>
>
> then instead of autoregistering the default listeners, we register this new listener with the appropriate events. for our particular use case this helped us out quite a bit.
>
> however, it looks as though we aren't going to be able to do this in the near future because of the redesign of EventSourceTransactionContext and FullTextIndexEventListener.
>
> EventSourceTransactionContext.getIndexWorkFlushEventListener looks thru the listeners for the FullTextIndexEventListener like so:
>
> for (FlushEventListener listener : flushEventListeners) {
> if ( listener.getClass().equals( FullTextIndexEventListener.class ) ) { return (FullTextIndexEventListener) listener; }
> }
>
> which means our subclass of FTIEL isn't be found. plus, it looks as though FTIEL will soon be final.
>
> so, i don't know if we've been "abusing" the system here, or what, but this seemed like a fairly straight forward way of implementing conditional indexing and has worked really well for us for quite some time.
>
> i'm not suggesting that hib-search make a dependency on MVEL, etc; however, it would be nice if we were able to continue to subclass FullTextIndexEventListener in the way that we have been.
>
>
> Project: Hibernate Search
> Components: mapping
> Affects Versions: 3.1.1.GA
> Fix Versions: 3.4.0
>
> Description
> In our system we have entities that are searched but not all of them are available for search - some of them are flagged as "removed". It would improve the efficiency of our search subsystem if we could implement a kind of "filter" that blocked these entities from being added to the search index, since we wouldn't have to make that a search term and our indexes would be somewhat smaller.
>
>
> This message was automatically generated by Atlassian JIRA Enterprise Edition, Version: 4.1-519 - Bug/feature request.
> If you think it was sent incorrectly, contact one of this server's administrators.
14 years, 11 months
svn2git migration steps ?
by Max Rydahl Andersen
Hi,
I'll be releasing the final version of hibernate tools to match what will be in jboss tools 3.2 soon and thought it would be a good time to
move the svn repo to git.
Anyone got the steps for how it was done for the rest that I could possibly reuse ?
Thanks,
Max
14 years, 11 months
Gradle and symlinks (again)
by Galder Zamarreño
Taking in account the big difference between 3.6 and master, particularly folder and ways to import into the IDE, I've gone and created two different folders for each branch with git-new-workdir, but Gradle once again does not like symlinks generated :(
For example:
git clone git@github.com:galderz/hibernate-core.git .repo
git-new-workdir .repo master master
cd master
gradle idea
:buildSrc:compileJava UP-TO-DATE
:buildSrc:compileGroovy UP-TO-DATE
:buildSrc:processResources UP-TO-DATE
:buildSrc:classes UP-TO-DATE
:buildSrc:jar UP-TO-DATE
:buildSrc:assemble UP-TO-DATE
:buildSrc:compileTestJava UP-TO-DATE
:buildSrc:compileTestGroovy UP-TO-DATE
:buildSrc:processTestResources UP-TO-DATE
:buildSrc:testClasses UP-TO-DATE
:buildSrc:test UP-TO-DATE
:buildSrc:check UP-TO-DATE
:buildSrc:build UP-TO-DATE
:hibernate-c3p0:ideaModule
Download http://repo1.maven.org/maven2/com/h2database/h2/1.2.145/h2-1.2.145-source...
:hibernate-core:ideaModule
:hibernate-ehcache:ideaModule
Download http://repo1.maven.org/maven2/net/sf/ehcache/ehcache-core/2.3.1/ehcache-c...
Download file:/Users/z/.m2/repository/net/sf/ehcache/ehcache-parent/2.1/ehcache-parent-2.1.pom
Download file:/Users/z/.m2/repository/org/slf4j/slf4j-api/1.5.11/slf4j-api-1.5.11.pom
Download file:/Users/z/.m2/repository/org/slf4j/slf4j-parent/1.5.11/slf4j-parent-1.5.11.pom
Download http://repo1.maven.org/maven2/net/sf/ehcache/ehcache-core/2.3.1/ehcache-c...
Download http://repo1.maven.org/maven2/org/slf4j/slf4j-api/1.5.11/slf4j-api-1.5.11...
Download http://repo1.maven.org/maven2/net/sf/ehcache/ehcache-core/2.3.1/ehcache-c...
Download file:/Users/z/.m2/repository/org/slf4j/slf4j-api/1.5.11/slf4j-api-1.5.11.jar
:hibernate-entitymanager:ideaModule
:hibernate-envers:ideaModule
:hibernate-infinispan:ideaModule
Download file:/Users/z/.m2/repository/org/infinispan/infinispan-core/4.2.0.CR4/infinispan-core-4.2.0.CR4-sources.jar
Download https://repository.jboss.org/nexus/content/groups/public/i18nlog/i18nlog/...
Download file:/Users/z/.m2/repository/org/jgroups/jgroups/2.11.0.GA/jgroups-2.11.0.GA-sources.jar
:hibernate-oscache:ideaModule
:hibernate-proxool:ideaModule
:hibernate-swarmcache:ideaModule
:release:ideaModule
:ideaModule
FAILURE: Build failed with an exception.
* What went wrong:
Could not list contents of '/Users/z/Go/code/hibernate-core.git/master/.git/remotes'.
* Try:
Run with -s or -d option to get more details. Run with -S option to get the full (very verbose) stacktrace.
BUILD FAILED
Total time: 1 mins 54.307 secs
Contents of master/.git are:
total 3264
drwxr-xr-x 15 z staff 510 Jan 25 10:17 .
drwxr-xr-x 29 z staff 986 Jan 25 10:22 ..
-rw-r--r-- 1 z staff 23 Jan 25 10:15 HEAD
-rw-r--r-- 1 z staff 313 Jan 25 10:17 MERGE_MSG
lrwxr-xr-x 1 z staff 53 Jan 25 10:15 config -> /Users/z/Go/code/hibernate-core.git/.repo/.git/config
lrwxr-xr-x 1 z staff 52 Jan 25 10:15 hooks -> /Users/z/Go/code/hibernate-core.git/.repo/.git/hooks
-rw-r--r-- 1 z staff 1625377 Jan 25 10:17 index
lrwxr-xr-x 1 z staff 51 Jan 25 10:15 info -> /Users/z/Go/code/hibernate-core.git/.repo/.git/info
drwxr-xr-x 4 z staff 136 Jan 25 10:15 logs
lrwxr-xr-x 1 z staff 54 Jan 25 10:15 objects -> /Users/z/Go/code/hibernate-core.git/.repo/.git/objects
lrwxr-xr-x 1 z staff 58 Jan 25 10:15 packed-refs -> /Users/z/Go/code/hibernate-core.git/.repo/.git/packed-refs
lrwxr-xr-x 1 z staff 51 Jan 25 10:15 refs -> /Users/z/Go/code/hibernate-core.git/.repo/.git/refs
lrwxr-xr-x 1 z staff 54 Jan 25 10:15 remotes -> /Users/z/Go/code/hibernate-core.git/.repo/.git/remotes
lrwxr-xr-x 1 z staff 55 Jan 25 10:15 rr-cache -> /Users/z/Go/code/hibernate-core.git/.repo/.git/rr-cache
lrwxr-xr-x 1 z staff 50 Jan 25 10:15 svn -> /Users/z/Go/code/hibernate-core.git/.repo/.git/svn
Anyway, regardless of the symlinks stuff, what's Gradle idea looking for stuff in .git folder?
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
14 years, 11 months
Small script to run your test suite in a cloned repo
by Emmanuel Bernard
It's easy to forget to add a file in a commit and then proposed an incomplete pull request.
Here is a small script that can help you prevent such things
$ build.sh
will clone the repo in your current directory and run 'maven clean install' off the current branch
if you've forgotten a file, the clone will not get it
$ build.sh clean test -pl module1,module2
will clone the repo in your current directory and run 'maven clean test -pl module1,module2l' off the current branch
https://gist.github.com/787631
This script has another advantage. Since the repo is cloned, you can go work on your next problem while the test suite run as your current directory is not where the test suite runs.
Of course this is maven specific but it can be easily adapted to run gradle.
HTH
Emmanuel
14 years, 12 months
JUnit 4.8
by Emmanuel Bernard
AFAIK we stayed on JUnit 3.8 to keep 1.4 compatibility.
Now that this is gone, what do you think about moving to JUnit 4.8
There are a few interesting new features besides the annotation goodness.
I am particularly interested in Rules which is essentially behavioral injection before / after test
http://kentbeck.github.com/junit/doc/ReleaseNotes4.7.html
What do you think?
15 years
Re: [hibernate-dev] [validator] Time to let go
by Emmanuel Bernard
On 17 janv. 2011, at 13:18, Hardy Ferentschik wrote:
> On Mon, 17 Jan 2011 13:06:07 +0100, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>
>> The main reason for keeping it around is that the latest stable release of Seam still uses it.
>> But the idea of tagging + deleting is find by me.
>
> Ok. I would hope though that any new release would use Validator 4 :)
>
Probable, but unless you follow what they are doing, and remind them, there is no guaranty :)
>
>> BTW how do you split a Git repo? simply by cloning and removing what you don't want?
>
> That would be the easiest approach. But I think if you want to do it properly
> you would have to use some git plumbing commands, eg filter-branch
>
True. That rewrites history though, right? Not sure it's something wanted.
15 years
Clever dirty checking for Hibernate Search
by Sanne Grinovero
Context:
As a follow-up on "HSEARCH-361 Only index an entity if an indexed
property has changed":
during development of this improvement we agreed to disable the
dirty-checking optimization in case a BoostStrategy or ClassBridge was
defined on the class;
we also considered the (unlikely) possibility that a FieldBridge could
access the full entity in some way, getting access to properties we
wouldn't expect (this case requires to disable the new feature).
So to fully support proper dirty check,some ideas where proposed to
add some way for ClassBridge/BoostStratey/... to define from which
properties they are affected.
Even if these implementations could list all property names, there are
drawbacks:
1) it breaks DRY. It's error prone, people could easily forget to
update the used-properties definition after fixing the main method.
2) doesn't take into account branches in the implementation. Maybe in
some cases it's affected by A,B, in some others by A,C depending on
the value of A.
3) pollutes all existing APIs.
Considering these drawbacks, I'm wondering if instead of the entity we
could pass to these implementations a proxied entity which could
record exactly which properties are being accessed.
The index would be not considered dirty if accessed properties aren't,
so further Document processing can be skipped.
I'd expect Hibernate core already has all required elements to
intercept and track access to managed entities?
Cheers,
Sanne
15 years
[validator] Time to let go
by Hardy Ferentschik
Hi,
I was wondering for quite some time what to do with the
hibernate-validator-legacy module of the current
Validator codebase.
It contains the old Validator 3.x code which originally wanted to keep
around. However, afaik there
was no activity against it for months if not even for years.
hibernate-validator-legacy slows down the overall build time, leads to
confusions when you are searching for
classes in the IDE and overall does not serve a real purpose.
I see two alternatives. Create a final tag and remove the module or create
a new git repo and move the code into
there. Given that lack of activity I would suggest the first option. We
can cross the bridge of creating a repo
for it, if we ever decide for another legacy release.
Thoughts?
--Hardy
15 years
missing ANTLR dependency from gradle built pom.xml
by Sanne Grinovero
Hello,
It seems that ANTLR is missing from the pom.xml generated by the new
gradle build of Hibernate Core.
The following patch seems to fix it but I couldn't find any
information on the "antlr( libraries.antlr )" line, from the
documentation is seems it's only being used to choose the ANTLR
version to use to generate the parser code, but I couldn't find an
option to also include it as dependency so I added an additional line.
Could anybody confirm this change is right? (It seems to work).
diff --git a/hibernate-core/hibernate-core.gradle
b/hibernate-core/hibernate-core.gradle
index 59f80aa..4f28e93 100644
--- a/hibernate-core/hibernate-core.gradle
+++ b/hibernate-core/hibernate-core.gradle
@@ -12,6 +12,7 @@ dependencies {
compile( libraries.commons_annotations )
compile( libraries.jpa )
antlr( libraries.antlr )
+ compile( libraries.antlr )
provided( libraries.javassist )
provided( libraries.cglib ) {
transitive = true
thanks,
Sanne
15 years
