[Hibernate-JIRA] Created: (HHH-5817) Passing char[] or byte[] to equal function of CriteriaBuilder throws java.lang.ClassCastException.
by Vyacheslav Dimitrov (JIRA)
Passing char[] or byte[] to equal function of CriteriaBuilder throws java.lang.ClassCastException.
--------------------------------------------------------------------------------------------------
Key: HHH-5817
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5817
Project: Hibernate Core
Issue Type: Bug
Components: entity-manager
Affects Versions: 3.6.0
Environment: Hibernate 3.6.0-Finale, derby db, mysql db, hsqldb
Reporter: Vyacheslav Dimitrov
Priority: Minor
Attachments: hibernate_3_6_0.patch
We have byte[] field in one of our entity and we want to make query like this.
{code}
byte[] var = ...;
Predicate p = builder.equal(root.get("ourByteField"), var);
criteria.where(p);
{code}
But this code throws exception:
[java] Exception in thread "main" java.lang.ClassCastException: [B cannot be cast to [Ljava.lang.Object;
[java] at org.hibernate.ejb.AbstractQueryImpl.registerParameterBinding(AbstractQueryImpl.java:349)
[java] at org.hibernate.ejb.QueryImpl.setParameter(QueryImpl.java:364)
[java] at org.hibernate.ejb.criteria.CriteriaQueryCompiler$1$1.bind(CriteriaQueryCompiler.java:194)
[java] at org.hibernate.ejb.criteria.CriteriaQueryCompiler.compile(CriteriaQueryCompiler.java:247)
[java] at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:441)
[java] at ru.petrsu.nest.oqlite.test.TestParser.main(TestParser.java:92)
[java] Java Result: 1
because class AbstractQueryImpl has code:
{code}
...
else if ( value.getClass().isArray() ) {
final Object[] array = (Object[]) value;
...
{code}
We offer to change this "if" like this
{code}
...
else if ( value.getClass().isArray() && value.getClass().equals(Object[].class)) {
final Object[] array = (Object[]) value;
...
{code}
Due to this new condition we get what we want and our criteria works fine. (At least ClassCastExceptio isn't occured).
Patch is attached (Also I can do pull request, if needed).
--
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
13 years
[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
13 years
[Hibernate-JIRA] Created: (HSEARCH-713) Drill-down faceting query should not affect other facet counts
by Sanne Grinovero (JIRA)
Drill-down faceting query should not affect other facet counts
--------------------------------------------------------------
Key: HSEARCH-713
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-713
Project: Hibernate Search
Issue Type: Improvement
Components: query
Reporter: Sanne Grinovero
Assignee: Hardy Ferentschik
Fix For: 3.4.0
Using the "drill-down" function in faceting should - at least by default - behave like Amazon's faceting: it affects the filtering of the list shown as current results but should not affect the faceting count of other facets.
(It will of course affect sub-facets, so people can navigate up/down the facet tree to narrow down the results and explore different branches, but the parent branch and it's peers shouldn't be affected.
It's still possible to apply global filters which affect all facets (like a filter applied on root): example enable "only items with at least 4 star reviews" might affect all counters in the tree.
But if I'm in the area "TVs", and then the options {"LED", "Plasma"} open up, when we select "LED" the counters for both "Plasma" and "LED" should not change -> just of course the main results list will show only LED televisions.
For those people who think it should be possible to affect such a drill down feature as a filter, they can still apply the filter globally (on the root query).
{quote}<emmanuel> but to move forward, let's start with what we have. It seems that such alternative are definitely going to be an option on the FacetedManager
<emmanuel> facetedManager.countAs(AMAZON) :){quote}
--
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
13 years