Hibernate Planning
by Hardy Ferentschik
Hi there,
I would like to start a discussion around a few 'management' questions.
1. What shall we do with commons-annotations? commons-annotations became a
module of Core (core/trunk/commons-annotations) when we moved
Annotations
and EntityManager into Core. Emmanuel, raised the question whether it
should
be really in Core or whether we should keep it seperate as independed
library.
I could also imagine to just move it back into Annotations itself. I
don't
think any other project really denpends on it (any project using
commons-annotations
uses also annotations). This would mean one less module/project to
manage.
2. Some changes to Hibernate Search require also changes to
Annotations/EntityManager.
This raises the question on how we handle releases now that these
modules are part
of the Core. Will we still do separate releases for these modules or
are we from now on
just doing 'full' Hibernate releases (meaning we always release Core
with all its modules)?
This question is especially interesting since we soon will start with
JPA 2 development.
3. Who is handling releases? So far Steve was basically driving the Core
releases, whereas Emmanuel
and I where looking after EntityManager, Annotations and Search. How
shall we do it now?
4. What is the current status on Hibernate 3.5? Is there already a
(interim) release planned?
It would be great to get some feedback and maybe we should at some stage
have a chat.
--Hardy
15 years, 2 months
hibernate search + indexing with transaction issue
by Yan Falken
Hi,
I have the following problem with indexing in transaction with hibernate
search: in case the transaction is opened and I want to perform multiple
work types - only one type is actually performed after the commit and the others are
ignored; example:
TransactionManager tm = new DummyTransactionManager();
tm.begin();
SEntity se1 = new SEntity(10, "first", "second", true);
Work delete = new Work(se1, "100", WorkType.DELETE);
Work add = new Work(se1, "100", WorkType.ADD);
Ctx ctx = new Ctx(tm.getTransaction());
searchFactory.getWorker().performWork(delete, ctx);
searchFactory.getWorker().performWork(add, ctx);
tm.commit();
only DELETE is performed - ADD is ignored
log:
2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [hibernate.search.default.indexBase] value: /tmp/c1idx
2009-03-23 13:45:02,195 TRACE main| MaskedProperty| found a match for key: [default.indexBase] value: /tmp/c1idx
2009-03-23 13:45:02,341 DEBUG main| BuilderIndexedEntity| Field selection in projections is set to false for entity problems.SEntity.
2009-03-23 13:45:02,502 DEBUG pool-1-thread-1| PerDPQueueProcessor| Skipping usage of an IndexWriter for updates
2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Locking Workspace (or waiting to...)
2009-03-23 13:45:02,503 TRACE pool-1-thread-1| PerDPQueueProcessor| Workspace lock aquired.
// opened
2009-03-23 13:45:02,503 DEBUG pool-1-thread-1| PerDPQueueProcessor| Opening an IndexReader for update
2009-03-23 13:45:02,503 TRACE pool-1-thread-1| Workspace| IndexReader opened
// only remove
2009-03-23 13:45:02,503 TRACE pool-1-thread-1| eleteExtWorkDelegate| Removing class problems.SEntity#100 by id using an IndexReader.
2009-03-23 13:45:02,539 TRACE pool-1-thread-1| Workspace| IndexReader closed
2009-03-23 13:45:02,539 TRACE pool-1-thread-1| PerDPQueueProcessor| Unlocking Workspace
I digged into the code a little bit and there is class method:
org.hibernate.search.engine.DocumentBuilderIndexedEntity.addWorkToQueue() which is in it's beginning iterating the existing queue to avoid unecessary duplicated works
if ( workType == WorkType.DELETE ) { //TODO add PURGE?
//DELETE should have precedence over any update before (HSEARCH-257)
//if an Add work is here, remove it
//if an other delete is here remember but still search for Add
if ( luceneWork instanceof AddLuceneWork ) {
toDelete.add( luceneWork );
}
else if ( luceneWork instanceof DeleteLuceneWork ) {
duplicateDelete = true;
}
}
else {
//we can safely say we are out, the other work is an ADD
return;
}
I believe that return should be changed to continue. I did several tests and after the change it can handle ADD/DELETE works in one queue.
Could you confirm this and tell me in case it's correct how fix should be raised? Please ignore this email if its design limitation and the multiple WTs cannot be fixed easily.
Thanks
YF
15 years, 2 months
HSearch programmatic mapping API
by Emmanuel Bernard
I have started working on that in the plane back home.
It's available upstream and requires the upstream commons-annotations
and annotations projects.
SearchMapping mapping = new SearchMapping();
mapping.analyzerDef( "stem", StandardTokenizerFactory.class )
.tokenizerParam( "name", "value" )
.tokenizerParam( "name2", "value2" )
.filter( LowerCaseFilterFactory.class )
.filter( SnowballPorterFilterFactory.class)
.param("language", "English")
.analyzerDef( "ngram", StandardTokenizerFactory.class )
.tokenizerParam( "name", "value" )
.tokenizerParam( "name2", "value2" )
.filter( LowerCaseFilterFactory.class )
.filter( NGramFilterFactory.class)
.param("minGramSize", "3")
.param("maxGramSize", "3")
.indexedClass(Address.class, "Address_Index")
.property("street1", ElementType.FIELD)
.field()
.field()
.name("street1_iso")
.store( Store.YES )
.index( Index.TOKENIZED )
.analyzer( ISOLatin1Analyzer.class)
.field()
.name("street1_ngram")
.analyzer("ngram")
.indexedClass(User.class)
.property("name", ElementType.METHOD)
.field()
.analyzerDef( "minimal", StandardTokenizerFactory.class );
configuration.getProperties().put( "hibernate.search.mapping_model",
mapping );
It works nicely (analyzerDef is not wired yet) and the mapping API
needs to be completed. A benefit is that it solves the problem
encountered by people willing to get XML mapping support in a much
nicer way.
It would benefit from a few additional pairs of eye before completing
the work.
http://forum.hibernate.org/viewtopic.php?p=2409404#2409404
http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-352
15 years, 2 months
Hibernate Search next version will target the latest Hibernate Core
by Emmanuel Bernard
We should target the upcoming version of Hibernate Core and
Annotations for Hibernate Search 3.2
New methods have been added to the Session so HSearch 3.2 will not
work on older Core versions and vice versa
I think we still should release a 3.1.1 with the work from Sanne on
out of transaction flushing. Sanne, is the patch easy to apply on a
different branch (a branch forking off the 3.1.0 tag)?
Steve, do you have a timeline for 3.5?
15 years, 2 months
[BVAL] POM Versions
by Alaa Mohsen
Hello guys,
I'm facing a problem right now, and the problem is that we currently
have Hibernate Validator Alpha 2 as a dependency in our project, which has
the Validation API Beta 4 as a dependency. The problem is that the latest
changes in the API (including those in the Message Interpolator) were
committed to Validation API Beta 4, and hence it made HV Alpha 2 unusable,
since it calls metheods that were changed in the API. I guess that the
current version should have been Beta 5 SNAPSHOT or something so that not to
break the older builds that depend on Beta 4.
Regards
Alaa Nassef
15 years, 2 months
Hudson jobs - cleanup and matrix X trigger
by Juraci Paixao Krohling
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
I was looking into our current Hudson jobs, and would like to suggest
some changes:
- - We currently have two views: Hibernate and Hibernate trunk. I propose
to remove Hibernate trunk and create a Hibernate EAP.
"Hibernate" would contain all community projects and all relevant
branches. Including the ones we don't have today.
"Hibernate EAP" would contain all EAP jobs, for binary testing and
branch testing. Hibernate Standalone would be here too, even though it
is not "EAP". Feel free to suggest a name which includes "EAP" and
"Standalone" :-)
- - All non-matrix jobs would be changed to matrix jobs.
Non-matrix jobs[1] are real jobs. As such, we can run a specific
configuration at any time we want. The problem is that we almost never
run a specific configuration (specially in community). Most of the jobs,
AFAIK, runs based on "scm pooling", so, keeping the view clean seems
more important than the ability to run specific configurations.
Matrix jobs are job containers which runs the same build for N
configurations, but the configuration itself is not a "real" job, in the
sense that we don't have a "Configure" option, nor "Build now". So, they
can only run as a whole (officially). But we are still able to create
temporary jobs if we need to run a specific configuration (like the
recent work with Sybase/MSSQL new dialects).
Also, currently we have some jobs which runs only on hsqldb. As you can
imagine, those jobs will be removed as part of this item, in favor of
matrix jobs.
Regarding some maven builds we have in Hudson: I'll remove them too.
They are not deploying artifacts to any public repository. They are
going only up to "install", which installs it on local hudson
repository. In the next step, I can setup a maven build which deploys to
some external public repository, but for now, I'd remove them to avoid
confusion.
The proposed changes, if nobody is against it, will take place in some
steps:
1) Move all current jobs to a temporary view: "Hibernate Trash"
2) Mark all jobs as "disabled"
3) Move the jobs we'll keep to the proper view (like, Branch_3_3 to
"Hibernate")
4) Mark those jobs as "enabled"
5) Create the missing jobs
6) One month after step 5, I'll permanently delete the jobs in Hibernate
Trash (as well as the view itself).
So, if you need some job, it will still be there for a month in
Hibernate Trash, but disabled. You'll need to enable it. But please,
just before you mark it as "enabled", do let me know. I can point you to
some appropriate job, or move it to the proper view if needed.
- - Juca.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkm6cCEACgkQPHUa7A/NqbogbACfV6DRORo5CFKnvpsi0V0Fvx/0
S5wAn2dzT0uD2Qx88tuUMMSSmqWWQZCT
=PSkq
-----END PGP SIGNATURE-----
15 years, 2 months
New to Dev List - Have a Patch
by Peter Harrison
Hi Everyone,
I'm working on a project using the Hibernate ant tools to generate DAO
objects for use inside a Spring context. The existing DAO exporter with
suffix "Home" uses JNDI to get the SessionFactory. However, Spring has its
own HibernateDaoSupport class which use dependency injection rather than
JNDI to determine the Sessionfactory. I could see that the classes I needed
were similar to the existing ones, but with modifications to extend the
HibernateDaoSupport and the dependency injection approach.
Bottom line is that I have downloaded the source and written a patch for
Hibernate Tools to actually create the Spring DAO objects. I essentially
copied the existing DAO export code, writing another exporter. The xml is
<hbm2springdao>. This addition does not introduce a hibernate dependency on
Spring. Although the generated code obviously will depend on Spring there
are no compile time dependencies on it introduced into the exporter itself.
Is this something you want to include in the main distribution? Who should I
submit the patch to?
15 years, 2 months
