[Search] Lazy initialization vs HSearch - Round 4
by Guillaume Smet
Hi,
Well, this time, I'm not sure we will be able to win the round by
ourselves so I'm asking for advice and guidance...
Following our recent patch submissions on the subject, we have one
problem left: when we're doing a mass import (note: this mass import
is really part of the application so we can't just disable Hibernate
Search during it), we have the following pattern:
Transaction {
for (items partitioned by 100) {
session.flush();
session.clear();
do work for these 100 items();
}
} -> indexing is done at the end of the transaction by Hibernate
Search automatically.
Note that we really need to flush the session otherwise it really
becomes too slow.
>From what we understand, when we clear the session, the entities are
detached from the session so the LuceneWorks executed when the
transaction is commited are working on detached entities. Are we
correct on this?
The fact is that following the addition of fetch = FetchType.LAZY in
certain relations, we start to have the following problems. Both are
related though.
I'm pretty sure we missed something as the problem seems obvious but
isn't reproducible without all the steps we have in our import. We
thought it might also be related to the fact that some entities might
come from the cache.
* Problem 1: it doesn't throw an exception but it doesn't sound right *
This code in AbstractDocumentBuilder.appendContainedInWorkForInstance()
is triggered as the session of the PersistentSet it's working on is
null:
try {
collection = getActualCollection( member, value );
collection.size(); //load it
}
catch ( Exception e ) {
if ( e.getClass().getName().contains(
"org.hibernate.LazyInitializationException" ) ) {
/* A deleted entity not having its collection initialized
* leads to a LIE because the collection is no longer attached to the session
*
* But that's ok as the collection update event has been processed before
* or the fk would have been cleared and thus triggering the cleaning
*/
collection = null;
}
}
-> the collection is then completely ignored but shouldn't be as we
are not working on a deleted entity.
* Problem 2: this time, the exception is not caught and it breaks our
mass import *
When Hibernate Search tries to index an entity, it throws a
LazyInitException in HibernateStatelessInitializer.unproxy() as, one
more time, the session of the lazy proxy is null: it triggers the
throw new LazyInitializationException( "could not initialize proxy -
no Session" ); in AbstractLazyInitializer.initialize().
The fact is that the trick we added in the unproxy() method of
HibernateLoadingSessionInitializer recently (see
https://github.com/openwide-java/hibernate-search/commit/2f7844857bfafb95...
and next commit on this file) cannot work as we don't have a session
in Hibernate*Stateless*Initializer.
We're kinda stuck here and I'm pretty sure we're missing something.
Any idea?
Thanks in advance.
--
Guillaume
13 years
Ensuring only Java 6 API is used when compiling with JDK 7
by Gunnar Morling
Hi all,
Recently Steve and I spoke on IRC about compiling code on JDK 7 but
targeting Java 6 for the built artifacts.
While setting source and target level to 1.6 makes sure that the source and
byte code are compliant with Java 6, there is still the possibility of
inadvertently using classes/methods introduced in Java 7, causing runtime
errors when executing that code on Java 6.
As I just learned, there's a tool called "Animal Sniffer" [1] which helps
to prevent this kind of error by checking a project against a given API
baseline, e.g. the Java 6 API. Using functionality not contained in that
API signature causes a build-time error.
As an example, I found out that we're using a method in HV which was
introduced only in Java 1.6.0_18, causing the code to fail on earlier Java
6 runtimes [2].
Animal Sniffer provides a Maven plug-in and an Ant task which I think
should also be usable with Gradle.
--Gunnar
[1] http://mojo.codehaus.org/animal-sniffer/
[2] https://hibernate.onjira.com/browse/HV-661
13 years
fix for https://hibernate.onjira.com/browse/HHH-766
by Stepan Yakovenko
HI!
StringHelper.firstIndexOfChar is extremely inefficient on long strings. It'd scan all string many times even if it starts with stop character. I propose to change it this way:
public static int firstIndexOfChar(String sqlString, String string, int startindex) {
Set stopchars = new HashSet();
for (int i = 0; i < string.length(); i++)
stopchars.add(string.charAt(i));
for (int i = startindex; i < sqlString.length(); i++) {
if (stopchars.contains(sqlString.charAt(i)))
return i;
}
return -1;
}
works fine in my project.
Stepan Yakovenko, stiv.yakovenko(a)mail.ru, +79039036253
13 years
4.1.9 delayed till tomorrow morning
by Brett Meyer
All, I'll do the 4.1.9 release first thing tomorrow (Thurs.) morning. There's a few tickets that are being finished up tonight. Tomorrow, please do not push anything to the 4.1 branch until the release is tagged. Sorry for the delay!
Brett Meyer
Red Hat Software Engineer, Hibernate
+1 260.349.5732
13 years
[metamodel] why not just give a generated name to constraint if no one provided in the mapping?
by Strong Liu
talking about org.hibernate.metamodel.spi.relational.AbstractConstraint#getName
proposing this :
public String getName() {
if ( name == null ) {
name = getExportedName();
}
return name;
}
reason:
I have to copy all the constraints defined in the root table to the sub table in a table-per-class hierarchy, w/o constraint name, it is hard to use "locate" methods, and I don't want to calculate generatedName() method many times.
alternative:
we add a defaultName / internalName attribute to the constraint, and use it for the internal constraint look up, the value is generated when constraint object created
wdyt?
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years
[Search] Useless dependency on solr-analysis-extras
by Guillaume Smet
Hi,
solr-analysis-extras is a big package as it comes with the following
dependencies:
3594568 2012-10-06 18:46 WEB-INF/lib/lucene-smartcn-3.6.1.jar
511956 2012-10-06 18:46 WEB-INF/lib/lucene-stempel-3.6.1.jar
which is 4 MB of dependencies which are usually not that useful
(stempel is a polish stemmer, smartcn is for chinese).
I checked and hibernate-search compiles perfectly when we remove the
dependency to solr-analysis-extras and we add a dependency to
solr-core as all the analyzers used by Hibernate Search (including
most of the locale dependent analyzers/stemmers) are now in
lucene-analyzers. IIRC, they were moved from solr-analysis-extras to
lucene-analyzers during the 3.x release cycle.
Apart from the size of the jars, as a lot of new Java features
(Servlet 3 related features for instance) are based on classpath
scanning, removing this useless dependency looks worthwhile to me.
So the plan is to replace the solr-analysis-extras dependency with
solr-core. I can work on a pull request if it looks sane to everyone.
Thanks for your feedback.
--
Guillaume
13 years
4.1.9.Final release on 12/12/12?
by Brett Meyer
We're still aiming to have the 4.1.9.Final release next Wed. (12/12/12). Please let us know if there are any objections or reasons to hold off.
And no, the world possibly ending on 12/21 isn't a reason ;)
Brett Meyer
Red Hat Software Engineer, Hibernate
+1 260.349.5732
13 years, 1 month
Contributors welcome: HSEARCH-809
by Sanne Grinovero
Looking into votes and forum comments pointing to HSEARCH-809 there is
a strong demand for this feature.
If someone is looking to contribute an interesting feature,
implementing this would make you very popular ;)
This is however not the very easy kind of tasks we usually suggest to
newcomers, it requires a bit of exploration and serveral unit tests..
still I think it's doable, and of course we're here to assist.
Cheers,
Sanne
https://hibernate.onjira.com/browse/HSEARCH-809
13 years, 1 month
relational model for union-subclass
by Strong Liu
having a design question, how should we model this
(correct me if I get this wrong)
for this inheritance hierarchy, the relational model of root entity is pushed to the sub entity, so the table of sub entity has all "root table" columns / pk
and depends on if root entity is abstract, there may or may not having a physical table for the root entity
we used this org.hibernate.mapping.DenormalizedTable to model a union subclass table, and also the Table class has a org.hibernate.mapping.Table#isPhysicalTable to tell schema tool if this table should be created or not
For the new Metamodel, as Gail and I discussed, we don't want to have some fake table even for the abstract root entity, NULL for the return value of EntityBinding.getPrimaryTable() is better and clean design.
but on the other hand, the DenormalizedTable design is quite simple to impl in the Binder ( I already get it works ), esp considering we bind root entity first and don't have second pass.
wdyt?
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
13 years, 1 month
