[Hibernate-JIRA] Created: (HHH-5235) MultipleHiLoPerTableGenerator infers catalogs and schemas where none should be inferred
by Laird Nelson (JIRA)
MultipleHiLoPerTableGenerator infers catalogs and schemas where none should be inferred
---------------------------------------------------------------------------------------
Key: HHH-5235
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5235
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5.2
Environment: Hibernate 3.5.2-Final, H2 database version 1.2.134
Reporter: Laird Nelson
I have a @TableGenerator annotation and an associated @GeneratedValue like this:
@Entity(name = "PostalAddress")
@TableGenerator(
name = "PostalAddressEntityIDGenerator",
table = "JPAGenerators",
pkColumnName = "generatorName",
pkColumnValue = "PostalAddressEntityIDGenerator",
valueColumnName = "generatorValue",
allocationSize = 1
)
public class PostalAddressEntity {
@GeneratedValue(strategy = GenerationType.TABLE, generator = "PostalAddressEntityIDGenerator")
@Id
private long id;
/* etc. */
}
At runtime, the following SQL shows up:
select generatorValue from JPAGenerators.JPAGenerators.JPAGenerators where generatorName = 'PostalAddressEntityIDGenerator' for update
Note the table name repeated three times as though it is both the catalog, the schema and the table name.
It seems that the MultipleHiLoPerTableGenerator, when asked to build its SQL strings for various operations, is told that the schema, the catalog and the table name are all the same.
I was expecting that the catalog would default to "", per the TableGenerator documentation, and that the schema would default to whatever was present in orm.xml's persistence-unit-defaults element.
I can work around this by explicitly spelling out the schema name in my @TableGenerator annotation, but I don't want to put it there (can't, actually). I can also work around this in a JPA-compliant manner by defining my table generator in my orm.xml file, but I don't want to do that either.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 9 months
[Hibernate-JIRA] Created: (HSEARCH-601) Allow MassIndexer to recover gracefully when individual objects won't index
by Ben Dotte (JIRA)
Allow MassIndexer to recover gracefully when individual objects won't index
---------------------------------------------------------------------------
Key: HSEARCH-601
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-601
Project: Hibernate Search
Issue Type: Improvement
Components: massindexer
Affects Versions: 3.2.0.Final
Environment: Hibernate 3.5.3, SQL Server 2005
Reporter: Ben Dotte
Some of our sites take hours to index, so it is critical that initial indexing complete even if some of the individual entities fail to index properly. Right now, it appears that the MassIndexer dies if any individual entity throws an exception during indexing, and does not complete indexing for that type.
I have a workaround for now by overriding EntityConsumerLuceneworkProducer with my own index() method that catches and logs exceptions from docBuilder.createAddWork():
private void index( Object entity, Session session ) throws InterruptedException {
Serializable id = session.getIdentifier( entity );
Class clazz = Hibernate.getClass( entity );
DocumentBuilderIndexedEntity docBuilder = documentBuilders.get( clazz );
TwoWayFieldBridge idBridge = docBuilder.getIdBridge();
String idInString = idBridge.objectToString( id );
//depending on the complexity of the object graph going to be indexed it's possible
//that we hit the database several times during work construction.
try
{
AddLuceneWork addWork = docBuilder.createAddWork( clazz, entity, id, idInString, true );
backend.enqueueAsyncWork( addWork );
}
catch (Exception e)
{
log.error("Error indexing " + clazz + " id " + id, e);
}
}
This has the added benefit that the object type and id that errored is logged, where that can be tough to track down otherwise.
That may not be the best solution in general since it could hide exceptions from Hibernate Search itself.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months
[Hibernate-JIRA] Created: (HSEARCH-349) Allow custom Loader in FullTextQueryImpl
by Julien Kronegg (JIRA)
Allow custom Loader in FullTextQueryImpl
----------------------------------------
Key: HSEARCH-349
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-349
Project: Hibernate Search
Issue Type: New Feature
Components: query
Affects Versions: 3.1.0.GA
Environment: Hibernate 3.3.1.GA, DB2
Reporter: Julien Kronegg
Priority: Minor
When doing an native SQL query containing join and other complicated stuff, one can get a List<MyObject> using the following code:
List<MyObject> list = entityManager.createNativeQuery("SELECT ...", MyObject.class).getResultList();
The MyObject class is an JPA Entity, but is not connected to a database table: the MyObject instance is reconstructed automatically by mapping the ResultSet column names and the MyObject field names.
This object list can be indexed using Hibernate Search (by adding @Indexed and @Field annotations to the MyObject entity). When doing an Hibernate Search query, the FullTextQueryImpl.list() method uses a Loader which try to load the MyObject entities from the database by a query such as "SELECT ... FROM MYOBJECT where id in (?,?,?,..)" (where the list of "?" is the list of identifiers returned by Lucene).
Here, we have a problem: the MYOBJECT table does not exist and obviously an exception is raised. The desired result would be for example to look into the initial List<MyObject> "list" instead of asking to the database.
This functionnality could be done very simply by adding a "Loader customLoader" field (with its public getter/setter) in the org.hibernate.search.query.FullTextQueryImpl class and by modifying the getLoader() method such as:
private Loader getLoader(Session session, SessionFactoryImplementor sessionFactoryImplementor) {
if (customLoader!=null) {
customLoader.init(session, sessionFactoryImplementor);
return customLoader;
}
...
}
After this modification, the programmer can design its own Loader which implements whatever loading strategy. For the example above, the Loader.load(EntityInfo[]) method may looks for each EntityInfo.id in the initially obtained List<MyObject> "list".
There is a workaround: copy the full source code of FullTextQueryImpl and add the described modifications.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 10 months