[Hibernate-JIRA] Created: (HSEARCH-770) Range facets: .below on numeric null values (AssertionFailure: Unsupported range type)
by Elmer van Chastelet (JIRA)
Range facets: .below on numeric null values (AssertionFailure: Unsupported range type)
--------------------------------------------------------------------------------------
Key: HSEARCH-770
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-770
Project: Hibernate Search
Issue Type: Bug
Components: query
Affects Versions: 3.4.0.Final
Environment: Using Hibernate 3.4.0 final, independent on on platform.
Reporter: Elmer van Chastelet
Attachments: RangeFacetNumericNullValueFail.zip
An assertion failure ("Unsupported range type") is thrown, when getting facets ( facetmanager.getFacets( facetName ) ) after narrowing on a facet ( facetmanager.getFacetGroup( facetingName ).selectFacets( facet )) in the following situation:
- Using a range facet with _.below_ constraint
- on a _numeric field_ (i.e. has @NumericField annotation)
- the field has a _null_ value for at least one indexed entity
Attached is a unit test that throws this exception.
My guess is that entities with null values are included in the result of the below facet, so probably null is evaluated to be 'lower' than any valid Integer. The lowest value found is probably used somewhere to set some range during .selectFacets( facetName ). This range is then used again when calling .getFacets( facetingName ), which tries to obtain the type from a null value -> AssertionFailure: Unsupported range type.
RangeFacetNumericNullValueFail.zip includes a unit test (testRangeBelowWithNullValues() in org.hibernate.search.test.query.facet.RangeFacetingTest) and the modified files which are used by this test (like Truck.java)
Exception trace:
org.hibernate.annotations.common.AssertionFailure: Unsupported range type
at org.hibernate.search.query.dsl.impl.RangeFacetImpl.createNumericRangeQuery(RangeFacetImpl.java:146)
at org.hibernate.search.query.dsl.impl.RangeFacetImpl.getFacetQuery(RangeFacetImpl.java:55)
at org.hibernate.search.query.engine.impl.FacetManagerImpl.createSelectionGroupQuery(FacetManagerImpl.java:160)
at org.hibernate.search.query.engine.impl.FacetManagerImpl.getFacetFilter(FacetManagerImpl.java:146)
at org.hibernate.search.query.engine.impl.HSQueryImpl.buildFilters(HSQueryImpl.java:650)
at org.hibernate.search.query.engine.impl.HSQueryImpl.getQueryHits(HSQueryImpl.java:384)
at org.hibernate.search.query.engine.impl.HSQueryImpl.queryDocumentExtractor(HSQueryImpl.java:275)
at org.hibernate.search.query.engine.impl.FacetManagerImpl.getFacets(FacetManagerImpl.java:110)
See also: [topic in Hibernate user forum|https://forum.hibernate.org/viewtopic.php?f=9&t=1011030]
--
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, 1 month
[Hibernate-JIRA] Created: (HHH-3028) Memory consumption when query cache is enabled
by Markus Heiden (JIRA)
Memory consumption when query cache is enabled
----------------------------------------------
Key: HHH-3028
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3028
Project: Hibernate3
Issue Type: Bug
Components: caching (L2), core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Oracle 9i
Reporter: Markus Heiden
As discussed in the hibernate-dev mailing list from 9.11.2007 to 12.11.2007 this bug describes a memory consumption issue which is located in ActionQueue/EntityAction.
Some snippets from ActionQueue:
private ArrayList executions;
public void execute(Executable executable) {
final boolean lockQueryCache = session.getFactory().getSettings().isQueryCacheEnabled();
if ( executable.hasAfterTransactionCompletion() || lockQueryCache ) {
executions.add( executable );
}
...
}
This code leads to a kind of memory leak, because if the "executable" is added to "executions", the related entity which is referenced from the "executable" is prevented from being garbage collected until the transaction ends. So if one needs to insert large amounts of transient objects in one transaction, there is no chance to get rid of the inserted objects by flushing and evicting them, if e.g. the query cache is enabled.
One solution to this problem might be to rework the above "if" condition to only add objects to "executions" if this is really needed. The problem is to determine when it is really needed.
Some snippets from EntityAction (which implements Executable):
private final Object instance;
public final Serializable getId() {
if ( id instanceof DelayedPostInsertIdentifier ) {
return session.getPersistenceContext().getEntry( instance ).getId();
}
return id;
}
public final Object getInstance() {
return instance;
}
Another solution might be to set the reference to the related entity (field "instance" in EntityAction) to null after flushing. This does not prevent "executions" from being filled, but the related entities might be garbage collected and so the memory consumption is acceptable. The problem is that subclasses of EntityAction use the "instance" field for post transaction work.
The are currently two workarounds to this problems:
1) To always disable the query cache
2) To use shorter transactions
Workaround 1 is not really acceptable, because it prohibits the use of a very useful feature.
Workaround 2 is sometimes acceptable but not wanted in most cases, because it breaks transactional safety.
--
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, 1 month
[Hibernate-JIRA] Created: (HSEARCH-597) Inconsistent treatment of extended FullTextIndexEventListener
by Ben Dotte (JIRA)
Inconsistent treatment of extended FullTextIndexEventListener
-------------------------------------------------------------
Key: HSEARCH-597
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-597
Project: Hibernate Search
Issue Type: Bug
Components: engine
Affects Versions: 3.2.0.Final
Environment: Hibernate 3.5.3, SQL Server 2005
Reporter: Ben Dotte
Priority: Minor
In my hibernate.cfg.xml file I have specified my own hibernate event listener class that extends from FullTextEventListener.java. ContextHelper nicely allows this (line 50):
if ( candidate instanceof FullTextIndexEventListener ) { ... }
However, with debug-level logging turned on, I see a number of log messages from EventSourceTransactionContext line 116 "FullTextIndexEventListener was not registered as FlushEventListener". This is because it looks for an exact class match:
if ( listener.getClass().equals( FullTextIndexEventListener.class ) ) { ... }
Could we change this to be FullTextIndexEventListener.class.isAssignableFrom(listener.getClass()) instead?
I also noticed an == check for the same thing in EventListenerRegister.isPresentInListeners().
--
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, 1 month
[Hibernate-JIRA] Created: (HSEARCH-681) NotSerializableException when NumericField gets serialized in JMSBackendQueueProcessor
by Katrin E. (JIRA)
NotSerializableException when NumericField gets serialized in JMSBackendQueueProcessor
--------------------------------------------------------------------------------------
Key: HSEARCH-681
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-681
Project: Hibernate Search
Issue Type: Bug
Affects Versions: 3.3.0.Final
Environment: Master-Slave-Architecture
Reporter: Katrin E.
We have a master-slave-architecture which delegates an index update to the master. We have NumericFields in the index to perform NumericRangeQueries. When the slave tries to inform the master via JMSBackendQueueProcessor the object including a NumericField gets serialized. A NotSerializableException occurs on a NumericTokenStream. The NumericField extends AbstractField, which implements Serializable, but it cannot be serialized because it stores the precisionStep in the underlying NumericTokenStream, which is not serializable.
This might be a lucene issue, but Hibernate Search gets affected for NumericRangeQueries. There is an issue on the lucene jira as well but isn't resolved yet:
https://issues.apache.org/jira/browse/LUCENE-2707
Here is a code snippet to test the serialization of a NumericField:
NumericField number = new NumericField("number", 4);
number.setFloatValue(42f);
try {
FileOutputStream fout = new FileOutputStream("number.txt");
ObjectOutputStream oos = new ObjectOutputStream(fout);
oos.writeObject(number);
oos.close();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
--
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, 1 month
[Hibernate-JIRA] Created: (HSEARCH-773) Example in documentation contains compilation erros
by Juraj Martinka (JIRA)
Example in documentation contains compilation erros
---------------------------------------------------
Key: HSEARCH-773
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-773
Project: Hibernate Search
Issue Type: Improvement
Reporter: Juraj Martinka
"Example 1.9. Using JPA to create and execute a search" contains compilation errors (probably copy & paste error :) ):
http://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single...
The correct version follows:
{code}
EntityManager em = entityManagerFactory.createEntityManager();
FullTextEntityManager fullTextEntityManager =
org.hibernate.search.jpa.Search.getFullTextEntityManager(em);
em.getTransaction().begin();
// create native Lucene query unsing the query DSL
// alternatively you can write the Lucene query using the Lucene query parser
// or the Lucene programmatic API. The Hibernate Search DSL is recommended though
QueryBuilder qb = em.getSearchFactory()
.buildQueryBuilder().forEntity( Book.class ).get();
org.apache.lucene.search.Query query = qb
.keyword()
.onFields("title", "subtitle", "authors.name", "publicationDate")
.matching("Java rocks!")
.createQuery();
// wrap Lucene query in a javax.persistence.Query
javax.persistence.Query persistenceQuery =
fullTextEntityManager.createFullTextQuery(query, Book.class);
// execute search
List result = persistenceQuery.getResultList();
em.getTransaction().commit();
em.close();
{code}
--
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, 2 months
[Hibernate-JIRA] Created: (HHH-3876) collection [] was not processed by flush() triggering for unknown reasons
by Mark Derricutt (JIRA)
collection [] was not processed by flush() triggering for unknown reasons
-------------------------------------------------------------------------
Key: HHH-3876
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3876
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.5
Reporter: Mark Derricutt
We've started to notice the following exceptions being triggered from Hibernate 3.5.0-SNAPSHOT (built locally), but only under certain circumstances (editing a specific user, whilst being logged into the application as a specific user). After stepping through both our application and hibernate through the whole update/commit process being run, I can't find anything that would be causing this problem.
During processing, I see calls to org.hibernate.engine.Collections#prepareCollectionForUpdate for CollectionEntry[smx3.schema.PartyRole.agreementsFrom#2006094] (and other elements in the same collection) which is listed in the trace below.
The collection which triggers the exception isn't consistently the same one, but seems to be localized to 4-5 different collections, I've also noticed that if I single-stepping through the process, if sometimes completes fine, which may indicate some race conditions somewhere.
As I'm not entirely sure why the exception is being thrown, I'm not sure if this is a problem with Hibernate, or something wrong in our application somewhere. Is there anyway I can identify why a collection entry wouldn't have been processed (and what does "processed" actually mean?).
24.04.2009 15:57:33.180 *ERROR* [btpool0-1] org.hibernate.AssertionFailure an assertion failure occured (this may indicate a bug in Hibernate, but is more likely due to unsafe use of the session) org.hibernate.AssertionFailure: collection [smx3.schema.PartyRole.agreementsFrom] was not processed by flush()
at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:228)
at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:356)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1031)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:369)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:88)
at com.atomikos.icatch.jta.Sync2Sync.beforeCompletion(Sync2Sync.java:73)
at com.atomikos.icatch.imp.TransactionStateHandler.commit(TransactionStateHandler.java:253)
at com.atomikos.icatch.imp.CompositeTransactionImp.doCommit(CompositeTransactionImp.java:509)
at com.atomikos.icatch.imp.CompositeTerminatorImp.commit(CompositeTerminatorImp.java:138)
at com.atomikos.icatch.jta.TransactionImp.commit(TransactionImp.java:297)
at com.atomikos.icatch.jta.TransactionManagerImp.commit(TransactionManagerImp.java:608)
at com.atomikos.icatch.jta.UserTransactionManager.commit(UserTransactionManager.java:148)
at smx3.envers.TransactionFilter.afterHandle(TransactionFilter.java:242)
at org.restlet.Filter.handle(Filter.java:197)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Filter.doHandle(Filter.java:150)
at com.noelios.restlet.StatusFilter.doHandle(StatusFilter.java:130)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at com.noelios.restlet.ChainHelper.handle(ChainHelper.java:124)
at com.noelios.restlet.application.ApplicationHelper.handle(ApplicationHelper.java:112)
at org.restlet.Application.handle(Application.java:341)
at org.restlet.ext.wadl.WadlApplication.handle(WadlApplication.java:705)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Router.handle(Router.java:504)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Router.handle(Router.java:504)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at com.noelios.restlet.ChainHelper.handle(ChainHelper.java:124)
at org.restlet.Component.handle(Component.java:673)
at org.restlet.Server.handle(Server.java:331)
at com.noelios.restlet.ServerHelper.handle(ServerHelper.java:68)
at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:147)
at com.noelios.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:881)
at nz.co.smx.rest.RestActivator$RestActivatorClassLoaderServlet.service(RestActivator.java:182)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:51)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722)
at org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:87)
at org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:63)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
24.04.2009 15:57:33.183 *WARN* [btpool0-1] atomikos Unexpected error in beforeCompletion:
org.hibernate.AssertionFailure: collection [smx3.schema.PartyRole.agreementsFrom] was not processed by flush()
at org.hibernate.engine.CollectionEntry.postFlush(CollectionEntry.java:228)
at org.hibernate.event.def.AbstractFlushingEventListener.postFlush(AbstractFlushingEventListener.java:356)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:51)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1031)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:369)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:88)
at com.atomikos.icatch.jta.Sync2Sync.beforeCompletion(Sync2Sync.java:73)
at com.atomikos.icatch.imp.TransactionStateHandler.commit(TransactionStateHandler.java:253)
at com.atomikos.icatch.imp.CompositeTransactionImp.doCommit(CompositeTransactionImp.java:509)
at com.atomikos.icatch.imp.CompositeTerminatorImp.commit(CompositeTerminatorImp.java:138)
at com.atomikos.icatch.jta.TransactionImp.commit(TransactionImp.java:297)
at com.atomikos.icatch.jta.TransactionManagerImp.commit(TransactionManagerImp.java:608)
at com.atomikos.icatch.jta.UserTransactionManager.commit(UserTransactionManager.java:148)
at smx3.envers.TransactionFilter.afterHandle(TransactionFilter.java:242)
at org.restlet.Filter.handle(Filter.java:197)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Filter.doHandle(Filter.java:150)
at com.noelios.restlet.StatusFilter.doHandle(StatusFilter.java:130)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at com.noelios.restlet.ChainHelper.handle(ChainHelper.java:124)
at com.noelios.restlet.application.ApplicationHelper.handle(ApplicationHelper.java:112)
at org.restlet.Application.handle(Application.java:341)
at org.restlet.ext.wadl.WadlApplication.handle(WadlApplication.java:705)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Router.handle(Router.java:504)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at org.restlet.Router.handle(Router.java:504)
at org.restlet.Filter.doHandle(Filter.java:150)
at org.restlet.Filter.handle(Filter.java:195)
at com.noelios.restlet.ChainHelper.handle(ChainHelper.java:124)
at org.restlet.Component.handle(Component.java:673)
at org.restlet.Server.handle(Server.java:331)
at com.noelios.restlet.ServerHelper.handle(ServerHelper.java:68)
at com.noelios.restlet.http.HttpServerHelper.handle(HttpServerHelper.java:147)
at com.noelios.restlet.ext.servlet.ServerServlet.service(ServerServlet.java:881)
at nz.co.smx.rest.RestActivator$RestActivatorClassLoaderServlet.service(RestActivator.java:182)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:362)
at org.ops4j.pax.web.service.internal.HttpServiceServletHandler.handle(HttpServiceServletHandler.java:51)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:722)
at org.ops4j.pax.web.service.internal.HttpServiceContext.handle(HttpServiceContext.java:87)
at org.ops4j.pax.web.service.internal.JettyServerHandlerCollection.handle(JettyServerHandlerCollection.java:63)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139)
at org.mortbay.jetty.Server.handle(Server.java:324)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:505)
at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:842)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:648)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:211)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:380)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:450)
--
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, 2 months
[Hibernate-JIRA] Created: (HHH-5301) Add support for parametrizing TYPE(e) expressions
by Luis Fernando Planella Gonzalez (JIRA)
Add support for parametrizing TYPE(e) expressions
-------------------------------------------------
Key: HHH-5301
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5301
Project: Hibernate Core
Issue Type: Bug
Components: query-hql
Affects Versions: 3.5.2
Environment: Hibernate 3.5.2, Java 6.0.20
Reporter: Luis Fernando Planella Gonzalez
Support parameters for JPA 2's TYPE(alias) function.
Test classes:
@Entity
@DiscriminatorColumn(name="subclass")
@Table(name="xs")
public abstract class XBase {
@Id
private Integer id;
public Integer getId() {
return id;
}
public void setId(Integer id) {
this.id = id;
}
}
@Entity
@DiscriminatorValue("x1")
public class X1 extends XBase {
@Basic
private String x1;
public String getX1() {
return x1;
}
public void setX1(String x1) {
this.x1 = x1;
}
}
@Entity
@DiscriminatorValue("x2")
public class X2 extends XBase {
@Basic
private String x2;
public String getX2() {
return x2;
}
public void setX2(String x2) {
this.x2 = x2;
}
}
Running the following query works: "select x from XBase x where type(x) = X1"
However, the following one: "select x from XBase x where type(x) = :t" yelds
Exception in thread "main" java.lang.UnsupportedOperationException: At the moment this type is not the one actually used to map the discriminator.
at org.hibernate.persister.entity.DiscriminatorType.nullSafeSet(DiscriminatorType.java:111)
at org.hibernate.param.NamedParameterSpecification.bind(NamedParameterSpecification.java:67)
at org.hibernate.loader.hql.QueryLoader.bindParameterValues(QueryLoader.java:567)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1612)
at org.hibernate.loader.Loader.doQuery(Loader.java:717)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:270)
at org.hibernate.loader.Loader.doList(Loader.java:2294)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2172)
at org.hibernate.loader.Loader.list(Loader.java:2167)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:448)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:363)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:196)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1258)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:102)
at org.hibernate.ejb.QueryImpl.getResultList(QueryImpl.java:241)
at test.Main.main(Main.java:28)
JPA 2's spec explicitly shows querying by type using parameters in section 4.6.17.4.
--
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, 2 months
[Hibernate-JIRA] Created: (HHH-5795) Allow Criteria#add(null)
by Joachim Durchholz (JIRA)
Allow Criteria#add(null)
------------------------
Key: HHH-5795
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5795
Project: Hibernate Core
Issue Type: Improvement
Components: core
Affects Versions: 3.6.0
Environment: Irrelevant
Reporter: Joachim Durchholz
Please allow using null as a Criterion in Criteria#add.
I'd like to write Criterion createFooBarFilter(x,y). It inspects both x and y, and returns a Criterion that compares property foo with x and property bar with y, provided X resp. Y are non-null (null values mean: do not filter).
If x is not null, the function returns Restrictions.eq("foo",x).
Likewise for Y.
If both are not null, return Restrictions.and(Restrictions.eq("foo",x),Restrictions.eq("bar",y)).
I'd like to return null if both x and y are null. This would pass a null to Criteria#add(null), but that crashes and burns miserably as soon as Hibernate wants to get the SQL string from such a Criterion.
So... how about modifying CriteriaImpl#add like this:
public Criteria add(Criterion expression) {
if ( expression != null ) {
add( this, expression );
}
return this;
}
--
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, 2 months