hferentschik

		private Serializable extractProperId(Work<T> work) {
			T entity = work.getEntity();
			// 1) entity is null for purge operation, which requires to trust the work id
			// 2) types mapped as provided id require to use the work id
			// 3) when Hibernate identifier rollback is used && this identifier is our same id source, we need to get the value from work id
			if ( entity == null
					|| documentBuilder.requiresProvidedId()
					|| ( work.isIdentifierWasRolledBack() && documentBuilder.isIdMatchingJpaId() ) ) {
				return work.getId();
			}

hferentschik

public class StoreNormsTest extends SearchTestCase {

	public void testStoreAndOmitNorms() throws Exception {
		Session session = openSession();
		FullTextSession fullTextSession = Search.getFullTextSession( session );
		Transaction tx = fullTextSession.beginTransaction();
		Test test = new Test();
		test.setWithNormsImplicit( "hello" );
		test.setWithNormsExplicit( "world" );
		test.setWithoutNorms( "how are you?" );

hferentschik

Continuing our journey towards Hibernate Search 4, we have decided to add a Beta2 to the schedule.

The main feature is the full abstraction of Hibernate Search from Hibernate Core. This is especially good news for Infinispan Query users who won't have to drag Hibernate Core and its dependencies anymore. It is now also possible to write an integration between Hibernate Search and another datastore: all the contracts have been fleshed out.

If we have done our job right, you will have nothing to change in your Maven dependency declaration. 'hibernate-search' is still the main artifact to include, but it is now just a shell depending on the new 'hibernate-search-orm' module.

On a completely different note we moved the Hibernate Search documentation to [Zanata=>https://translate.jboss.org] which is a web-based system for translators to translate documentation using a web-browser. So far it was quite hard for translators to just contribute with translations. They had to checkout the source code, install the [

hferentschik

	@Test
	public void testWithClassBridge() {
		EntityManagerFactory factory = new HibernatePersistence().createEntityManagerFactory( new HashMap() );
		factory.close();
		testScenario( true, 2, false );
	}

hferentschik

[color]
        ui = auto
        
[color "branch"]
       current = black reverse
       local = black
       remote = green
        

hferentschik

@Entity
@Indexed
public class Foo {

        @Id
	public Long id;

        @Field
	public String name;

hferentschik

		return attributeBindingContainer.makeBagAttributeBinding( attribute,
																  pluralAttributeElementNature( attributeSource ),
																  pluralAttributeKeyBinding( attributeBindingContainer,
																							 attributeSource ),
																  propertyAccessorName( attributeSource ),
																  attributeSource.isIncludedInOptimisticLocking(),
																  false,
																  createMetaAttributeContext( attributeBindingContainer,
																							  attributeSource ) );

hferentschik

A question which came up recently a lot was the question about the release plan for Hibernate 
Validator 4.3. It is time for an answer.

I used to say that Validator 4.3 will align with Bean Validation 1.1, incorporating any changes 
required for this specification update. Work on BV 1.1 is still in full swing and it is still time
to raise your voice for your long missed validation feature. Check out 
[beanvalidation.org=>http://beanvalidation.org/] for information.

Back to Hibernate Validator though. Over the last few months we incorporated a bunch of useful
changes and bug fixes into the code base. For example all string based *ConstraintValidator*s 

hferentschik

Moving along the road to a Hibernate Validator 4.3 release I am happy to announce the release of Hibernate Validator 4.3.0.Beta1.

One of our foci this time around was to address existing caching issues. HV-479 addresses the problem that the constraint metadata for a given class would be cached in the so called BeanMetaDataManager without a appropriate eviction policy. In most cases this should not be a problem, but for long running applications with for example hot redeploys it could be. We resolved this issue by introducing SoftLimitMRUCache which has an upper bound for the cached metadata.

HV-564 is another caching related issue. Initally ConstraintValidator instances were only cached if they where created by the Hibernate Validator specific _ConstraintValidatorFacto

hferentschik

/*
* JBoss, Home of Professional Open Source
* Copyright 2009, Red Hat, Inc. and/or its affiliates, and individual contributors
* by the @authors tag. See the copyright.txt in the distribution for a
* full listing of individual contributors.
*
* Licensed under the Apache License, Version 2.0 (the "License");
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
* http://www.apache.org/licenses/LICENSE-2.0