Hibernate Search, more API changes in SearchFactory
by Sanne Grinovero
Hello,
I'm thinking to hide the ReaderProvider API from the public interface;
it will still be available at SPI level, but I would prefer to keep
the option open to remove the ReaderProvider altogether in a near
future (replacing it by something similar).
This API is currently used when the end user needs "low level" access
to the index by getting control of an IndexReader, but currently he
needs to pass in the DirectoryProviders (gone already),
so I'd transform the API usage from current:
DocumentBuilder builderForX = searchFactory.getDocumentBuilder();
DirectoryProvider[] targetDps = // find out which DPs you want from
each documentBuilder (??? -- quite some questions on this usually)
IndexReader indexreader =
searchFactory.getReaderProvider().openReader( targetDps );
try {
//play with reader
}
finally {
searchFactory.getReaderProvider().closeReader( indexReader );
}
into this:
IndexReader indexReader = getSearchFactory().openIndexReader(
LargeDocument.class, OtherType,class );
try {
//play with reader
}
finally {
searchFactory.closeReader( indexReader );
}
Or for the closing stage we could go so far to require only
indexReader.close();
Keeping the current API is not an option unless we throw away all what
I've already done for (HSEARCH-750, HSEARCH-761).
This is already in my current experimental branch, without the
"indexReader.close()" option as I'm not liking the asymmetry of the
operation (closing it differently than how I opened it).
WDYT?
Sanne
12 years, 9 months
Interested in helping a research study on Eclipse?
by Mohsen Vakilian
Hi
I'm Mohsen, a PhD student working with Prof. Ralph Johnson at the University of Illinois at Urbana-Champaign (UIUC). Ralph is
a co-author of the seminal book on design patterns (GoF) and his research group has a history of important contributions to
IDE's.
Our team [1] is studying how developers interact with the Eclipse IDE for evolving and maintaining their code. We are extending
this invitation to expert Java developers and would greatly appreciate and value your participation and help in our research
study. We know that some of you use IntelliJ IDEA to contribute to Hibernate. And, we're sending an invitation to this mailing
list just in case some of you use Eclipse for contributing to open source projects.
To participate you should be at least 18 years old and use Eclipse Helios for Java development. As a participant, we ask that
you complete a short survey and install our Eclipse plug-in called CodingSpectator [2].
CodingSpectator monitors programming interactions non-intrusively in the background and periodically uploads it to a secure
server at UIUC. To get a representative perspective of how you interact with Eclipse, we would appreciate if you could install
CodingSpectator for two months. Rest assured that we are taking the utmost measures to protect your privacy and
confidentiality.
If you are interested, you may sign up at <http://codingspectator.cs.illinois.edu/ConsentForm>, which contains our consent form
with all the details and procedures of our research study.
Your participation will help us greatly as we try to better understand how developers interact with their IDE's so we can propose
improvements which fit better with their mindsets.
Thanks in advance for your time! Please do not hesitate to contact me (mvakili2(a)illinois.edu) if you have any questions or
comments. More information can also be found at our FAQ [3]. Feel free to forward this invitation to anyone who might be
interested in participating in this study.
--
Mohsen Vakilian
& the CodingSpectator team
[1] http://codingspectator.cs.illinois.edu/People
[2] http://codingspectator.cs.illinois.edu
[3] http://codingspectator.cs.illinois.edu/FAQ
12 years, 9 months
HSEARCH-761 & JMS backends
by Sanne Grinovero
Hello all,
With HSEARCH-761 each index can be configured with a separate backend;
one possible configuration is a "multi-master" in which LuceneWork
operations related to different indexes are sent to different
backends, possibly on different cluster nodes but not necessarily.
So while before the "target index" was part of the message as it could
be inferred from the operations and involved indexed classes, now it's
a metadata attached to the message as a receiving backend could assume
that all operations it receives need to be applied and the only index
it's managing, but I still want to transmit it so that a single
backend will still optionally be able to handle multiple indexes, as
it did before.
Different backends are mapped by the index name, eventually with a
shard postfix, so I need to label the messages with a String for the
receiver to know how to deal with them.
Shall I attach this as a JMS "stringProperty", or shall I encode it as
part of the payload?
I think it should be a property so that people can deal with it in
flexible "JMS ways", but I'm not sure. Both strategies are easy to
implement.
Regards,
Sanne
12 years, 9 months
OGM abstraction contract
by Emmanuel Bernard
I've made some progress on the abstraction contract between OGM and the underlying store.
I've introduced the notion of Tuple that can then be converted in whatever the store pleases (AtomicMap for example in Infinispan's case).
Let me know if you think that's going in the right direction
https://github.com/emmanuelbernard/hibernate-ogm/tree/OGM-69
Note that I have not converted associations yet which is why some code esp in OgmCollectionPersister copy data back and forth between the Tuple model and the Map model.
12 years, 9 months
Static meta-model and references to SessionFactoryImpl
by Gunnar Morling
Hi,
while analyzing a memory leak I noticed that instances of the static
JPA 2 meta model seem to hold references to Hibernate's session
factory. In my case the path to the factory is the following:
SingularAttributeImpl#attributeType ->
EmbeddableTypeImpl#hibernateType -> ComponentType#typeScope ->
TypeScopeImpl#factory
Since the members of the meta model are static I think that means that
the factory won't be GC'ed although it was closed by the application,
hence consuming memory otherwise not needed anymore. WDYT, is this an
issue that should be addressed? Or are the meta model instances
removed at some point of time? I don't know really much about
Hibernate Core, so I hope my questions are not completely clueless ;-)
Thanks,
--Gunnar
12 years, 9 months
AvailableSettings.USE_NEW_METADATA_MAPPINGS
by Gail Badner
I've added a new setting, AvailableSettings.USE_NEW_METADATA_MAPPINGS, that tells BaseCoreFunctionalTestCase to build the SessionFactory from the new metadata.
I've checked in a new test, org.hibernate.test.ops.SimpleOpsTest, that configures this new setting and successfully saves, updates, gets, loads, merges and deletes an entity with a basic property.
For now, Configuration is still used to set up properties for the test and create the BasicServiceRegistry before building the metadata and session factory.
Currently, Configuration does not support HBM XML using hibernate-mapping-4.0.xsd and the headers on existing HBM XML mappings result in exceptions when applied to MetadataImpl.
I'm not sure how that should be remedied.
Time to get some sleep...
Gail
12 years, 9 months
[Search] Future of branch 3.4.x
by Sanne Grinovero
Hello,
Are we going to release a 3.4.1 version of Hibernate Search at some point?
There are some community members asking if there is any plan, and if
there's an expected timeframe.
There where some issues with the new features in 3.4.0, the most
urgent ones where quickly reported and fixed since that people is
using 3.5.0 snapshots.
Some other fixes in the faceting are are still to be done, but I
remember Hardy mentioning they should be easy.. ideally we could merge
these too, iff there's such an intention.
I had created a 3.4.x branch only recently from the 3.4.0 release tag:
this means it's not containing all of the fixes which are in master.
Cheers,
Sanne
12 years, 9 months
