Hibernate Search 4.0 Final
by Emmanuel Bernard
The team is pleased to announce the release of Hibernate Search 4.0 Final available in a SourceForge and Maven repository near you.
The main changes are
- support for Hibernate Core 4
- support for source of data/events other than Hibernate Core (which is now an optional dependency)
- clearer split between APIs, SPIs and implementation classes
- better log and error reporting
- better underlying architecture - index managers allow now for one backend per index and even non directory based indexes
- near real time search
- optimized and cross-version compatible wire format for communications between master and slaves
- performance improvements (more analyzer parallelization etc)
- support for projections on custom bridges fields
- support for @IndexedEmbedded on collections of basic types
- easier way to work on documentation translation
More info at http://goo.gl/pZILz
Happy holidays
Emmanuel
14 years, 9 months
trying to serialize an extended persistence context and not yet serializable errors with Hiberante 4.0.0.CR7 ...
by Scott Marlow
I'm trying to serialize an extended persistence context from an AS7 unit
test, which involves serializing whatever
org.hibernate.service.internal.StandardServiceRegistryImpl.wroteObject
includes.
I started getting working on this last night and have worked through the
AS7 ModuleClassLoader and DataSource objects so far. The next
NotSerializableException is for the
org.hibernate.service.internal.StandardServiceRegistryImpl instance.
The exception call stack is here http://pastie.org/3018508
I just wanted to let people know that I'm investigating this.
Scott
14 years, 9 months
Re: [hibernate-dev] Hibernate Core | Merge to 4.0 | Batcher API removed - what should I use instead?
by Gail Badner
I've updated "Hibernate Core Migration Guide : 4.0" to give some details about the changes in batching.
I don't see anything in the documentation about hibernate.jdbc.batch.builder, the property that BatchBuilderInitiator uses to specify the BatchBuilder implementation. Should properties used by the initiators be documented?
Regards,
Gail
----- Original Message -----
> From: "Arik Goldstein" <arikgold(a)checkpoint.com>
> To: "gavin king" <gavin.king(a)gmail.com>, gbadner(a)redhat.com
> Sent: Thursday, December 8, 2011 4:21:33 AM
> Subject: Hibernate Core | Merge to 4.0 | Batcher API removed - what should I use instead?
>
>
>
>
> Hi Gavin & Gail,
>
>
>
> • I work with Hibernate on a new project.
>
>
>
>
> • I am in the process of upgrading hibernate core from 3.6.2 to
> 4.0.0
>
>
>
>
> • I am using Batcher, and BatchingBatcher classes that removed as
> part of issue
>
>
> https://hibernate.onjira.com/browse/HHH-5778
>
>
>
> • What should I use instead? Is there any example? I didn’t find
> any documentation for that.
>
>
>
>
> Thanks in advance,
>
>
>
> Arik Goldstein | Software Developer| Management Technology Group
> Check Point Software Technologies | ( +972-3-611 5131
>
>
14 years, 9 months
CacheKey serialization
by Alex Snaps
Hey guys,
Some user on our forum refers to a jira he filed on the Hibernate bug
tracker : HHH-6880
I believe this was introduced in 3.6 when HHH-5182 was addressed. Am I
missing something or is this a genuine issue ?
When clustering with Terracotta, we use our own Serialization
mechanism that will not be affected. But users using persistent
caches, or replicated caches would suffer from this afaict. So would
users of 2 level-cache that do use on "plain-old Java Serialization".
Anyways, just wanted to get your opinion on this.
Thanks,
Alex
--
Alex Snaps <alex.snaps(a)gmail.com>
Senior Software Engineer - Terracotta
http://twitter.com/alexsnaps
http://www.linkedin.com/in/alexsnaps
14 years, 10 months
HSEARCH-638 and other Search fixes.. another RC?
by Sanne Grinovero
I had created a testcase for HSEARCH-638 [1] quite some time ago, and
Davide was now so kind to take it over and implement the solution
which is almost ready in a pull request.
In my opinion, HSEARCH-638 is a performance bug and should be fixed.
When we last talked about it, Emmanuel was not considering it being
bug, as it was exactly expressing it's original intention.. I believe
we settled by saying it would be fine to change the behaviour, BUT he
would not consider it a bug fix but an API change as it would affect
possible users: indeed that's correct, as it changes what is exactly
included in the index, but how I was seeing the index mapping I doubt
anybody was relying on it.
So now we have a fix, and the project lead considers it an API change.
This was the original reason for me when I made the tests for it, to
not provide a solution yet, as it would need to wait for 4.0 .. now we
have the solution so I think we should rather merge it now than to
wait as it might be considered an API change (although I'm not overly
convinced of that).
Problem is that it's a bit late in the 4.0 train. If you think it's
acceptable to make another RC soon, then I'd love to include this and
also propose a solution for HSEARCH-598 (MassIndexer freezes when pool
size is too low), as I have a POC for it but it's not trivial so I
won't send a pull request (nor spend more time on it) unless we'll
make another RC.
If we could, I'd include two other API changes:
- HSEARCH-800 Should we move ORM related APIs to
org.hibernate.search.orm? Today they are in org.hibernate.search
- HSEARCH-795 Move some of SearchFactoryImplementor from spi to impl
(and move SPI level contracts up)
should these otherwise be rejected?
Sanne
1 - Limit graph traversal by @ContainedIn to the minimum required path
- https://hibernate.onjira.com/browse/HSEARCH-638
14 years, 10 months
Hibernate OGM split in modules, ready for new integrations!
by Sanne Grinovero
Hi Greg,
we've implemented all changes in Hibernate OGM which we discussed at
Devoxx to make it easier for you to create a new module and get
started experimenting with an EHCache integration.
Actually to proof myself correct I've already created a new module,
and removed Infinispan from the main module relegating it in it's own
extension; so while in the main pom and possibly in some comments and
documentation Infinispan might still be mentioned as the "main"
supported engine, it's not the case anymore as far as the
implementation concerns: the tests of the core module are now using a
"spiced" ConcurrentHashMap instead and we'll improve on the docs too
as soon as we actually have an alternative. I hope this will let you
get started quickly, basically you only have to look into the
Infinispan module and think how to best implement the 6 trivial
classes.
The structure of the testsuite might need some warnings: since the
tests verify the functionality via the user API, we actually want to
re-run all the tests on each database. That's what Hibernate Core
always did, via a couple of properties it switches the JDBC driver and
connection details, just one class cares for the dialect which
encapsulates the database specifics; but most code is well tested
using a single database, so by default the testsuite runs H2 only,
while Jenkins re-runs the full testsuite on all supported databases.
In the case of Hibernate OGM, the code which we actually want to test
is the integration with each database, so running tests on only one of
them is not really an option.
To re-run the same testsuite multiple times, and to keep all the
database specific code and dependencies in different modules, we're
hacking a bit around Maven by packaging the testsuite from the main
module and referring to the same tests again in each module.
Basically I'd suggest to have a look at how the
hibernate-ogm-infinispan module reuses the test code from
hibernate-ogm-core; most of the magic is triggered by the
maven-dependency-plugin in the parent pom.xml and the
org.hibernate.ogm.test.utils.InfinispanTestHelper in the test sources.
Of course you can add additional EHCache tests as you like in the new
hibernate-ogm-ehcache module, but I'd suggest to reuse all tests from
hibernate-ogm-core.
We can certainly polish this approach if it doesn't proof sound in
practice, but I hope it's a good way to get started with it. It should
provide some convergence of features across "databases"; if some
feature can really not be implemented we can introduce flags to
disable groups of tests in specific modules; for now there exists one
such flag which disables JTA integration [1] : I'm using it with the
Map implementation as I didn't implement transactional support on it.
In theory you could introduce more such flags if you really need to
disable some other tests, but that would be the least desirable option
as we hope to provide a consistent behaviour across different backing
databases as much as possible.
The basic build information can be found here:
http://docs.jboss.org/hibernate/ogm/3.0/reference/en-US/html/ogm-howtocon...
For any question, we're looking forward to help you!
Regards,
Sanne
1 - org.hibernate.ogm.test.utils.TestableGridDialect.backendSupportsTransactions()
14 years, 10 months
