[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, 3 months
[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, 3 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, 3 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, 3 months
[Hibernate-JIRA] Created: (HV-389) Support conditional validation at property level
by jason shi (JIRA)
Support conditional validation at property level
------------------------------------------------
Key: HV-389
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-389
Project: Hibernate Validator
Issue Type: New Feature
Components: engine
Affects Versions: 4.1.0.Final
Reporter: jason shi
Assignee: Hardy Ferentschik
In Oval, there is a "when" attribute in each ConstrainsChecker,which can be used for conditional check.
In the following example fieldB must not be null only if fieldA is not null as well. With the prefix groovy: it is indicated that the formula is expressed in the Groovy language.
{code}
public class BusinessObject
{
private String fieldA;
@NotNull(when = "groovy:_this.fieldA != null")
private String fieldB;
}
{code}
Although we can use ScriptAssert as a work-around, but ScriptAssert can't be used at property level validation, and the "when" attribute make the validation logical more clearly.
In UI layer validation, this feature is very important in instant UI validation.
The hibernate validator should have the ability to pass a ValueContext to the Validator,then we can write a custom Contrains to implement this feature.
--
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, 3 months
[Hibernate-JIRA] Created: (HBX-1081) Generation of meta attributes for composite-id
by Anders Reinhardt Hansen (JIRA)
Generation of meta attributes for composite-id
----------------------------------------------
Key: HBX-1081
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1081
Project: Hibernate Tools
Issue Type: Improvement
Components: reverse-engineer
Affects Versions: 3.2.beta11
Environment: All, not related to platform.
Reporter: Anders Reinhardt Hansen
Priority: Minor
The ReverseEngineeringStrategy has a method; "public Map tableToMetaAttributes(TableIdentifier tableIdentifier)"
This method returns a Map of meta tags which will be put inside the class node of the hbm files that are generated.
It would be a nice addition if we could have a method like this which placed meta tags inside the composite id node.
the method could be called "public Map tableToMetaAttributesForCompositeId(TableIdentifier tableIdentifier)"
An example of the problem is shown in the below example;
<class name="XXX1" table="XXX1">
<meta attribute="generated-class">XXX1Base</meta> <!-- this can be generated by tableToMetaAttributes() -->
<composite-id name="XXX2" class="XXX2">
<meta attribute="generated-class">XXX2Base</meta> <!-- this cannot be generated -->
<key-property name="propertyXXX" type="int">
<column name="ColoumnXXX" />
</key-property>
<key-property name="YYY" type="int">
<column name="ColoumnYYY" />
</key-property>
</composite-id>
...
</class>
The issue was discussed on the forum in topic http://forum.hibernate.org/viewtopic.php?t=989476
--
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, 3 months
[Hibernate-JIRA] Created: (HHH-3305) hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default
by Jim Doyle (JIRA)
hbm2ddl: MS SQL Server 2005 defaults to Clustered Index on PK, lets use PRIMARY KEY NONCLUSTERED for hbm2ddl as a more reasonable default
-------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-3305
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3305
Project: Hibernate3
Issue Type: Bug
Components: metamodel
Affects Versions: 3.2.1
Reporter: Jim Doyle
In SQL Server 2005, PRIMARY KEY defaults to creating a Clustered Index for the PK column at table creation time.
To confirm this behaviour Please see: http://msdn.microsoft.com/en-us/library/ms188066.aspx
This default behaviour is un-desireable for a number of reasons:
1. No other databases default to a clustered IDX at the PK ; Not DB2, nor Oracle nor MySQL
2. There may only be ONE clustered IDX per table. By using this as a default makes it difficult
for the app developer or DBA to quickly add or change the once-per-table opportunity to use
the cluster to improve query performance.
3. The default cluster index that Microsoft applies seems only to benefit naive SQL server users with
little to no DBA skills. Table insert of new rows onto a Clustered Index PK is always very fast and
while this optimization may be impressive if your problem space is rapidly inserting new data into large tables,
this optimization is often an antipattern to users with more plausible query patterns such as scan by non-primary
key date, numeric amounts or alphabetical data.
4. Defaulting the PK to clustered creates SUBSTANTIAL burden for a DBA when the Clustered Index needs to be removed
from the PK to be deployed on other columns on the table. As an example of the burden that this creates, for EACH TABLE
one must:
- Discover all tables and columns that link back to the table in question through FOREIGN KEY
- Drop all foreign keys
- Drop the PK
- Add the PK back, with NONCLUSTERED
- Put back all the dropped Foreign keys
5. Additional arguments against supporting Microsoft's unusual default is given here:
http://tonesdotnetblog.wordpress.com/2008/05/26/twelve-tips-for-optimisin...
(Please See Section 2: Use Clustered Index).
I propose ANY ONE of the following enhancements to the DDL generator for the SQL Server 2005 Dialect:
1. Change the generated SQL from colname coltype PRIMARY KEY TO colname coltype PRIMARY KEY NONCLUSTERED such that
PK index generate conforms the the usual, sensible defaults of other database products.
2. Use a Properties attribute (i.e. hibernate.hbm2ddl.dialect.mssql.use_non_clustered_pk) that is evaluated at hbm2ddl runtime
that will emit 'NONCLUSTERED' to the PK clause. If this Property is not defined, the hbm2ddl will simply emit PRIMARY KEY as it does
now and MS SQL Server will use its peculiar and annoying default.
--
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, 3 months
[Hibernate-JIRA] Created: (ANN-758) map key type no longer inferred correctly, throws exception at runtime
by David Mansfield (JIRA)
map key type no longer inferred correctly, throws exception at runtime
----------------------------------------------------------------------
Key: ANN-758
URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-758
Project: Hibernate Annotations
Issue Type: Bug
Components: binder
Affects Versions: 3.3.1.GA
Environment: hib. 3.2, annotaions 3.3.1GA, em 3.3.1GA, oracle 10r2, tomcat 5.5, linux, spring 2.0
Reporter: David Mansfield
Attachments: hib-anno-set-map-key-type.patch
after upgrading from annotations 3.3.0GA to 3.3.1GA, my mapped collection (ManyToMany) is broken. i've identified the commit that broke it:
http://fisheye.jboss.com/browse/Hibernate/annotations/trunk/src/java/org/...
The issue is that unless the type is given now expliticly in the @MapKey's @Type, the code now assumes a 'Serializable' type, and attempts to deserialize an object stream from the database column value. the exact exception is:
java.io.StreamCorruptedException: invalid stream header
at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:764)
at java.io.ObjectInputStream.<init>(ObjectInputStream.java:277)
at org.hibernate.util.SerializationHelper$CustomObjectInputStream.<init>(SerializationHelper.java:252)
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:209)
at org.hibernate.util.SerializationHelper.deserialize(SerializationHelper.java:240)
at org.hibernate.type.SerializableType.fromBytes(SerializableType.java:82)
at org.hibernate.type.SerializableType.get(SerializableType.java:39)
at org.hibernate.type.NullableType.nullSafeGet(NullableType.java:163)
...
The fix is simple: if @Type is NOT given in the @MapKey annotation, keep the old behavior which at least tries to set the type, even if it may not work in all situations. The attached patch fixes the problem for me.
In my particular situation, the map key type is a java.lang.Enum. Here's what my annotated property looks like:
@ManyToMany
@JoinTable(
name="chargeback_owner"
,joinColumns=@JoinColumn(name="person_id",referencedColumnName="person_id")
,inverseJoinColumns=@JoinColumn(name="owner_person_id")
)
@MapKey(columns=@Column(name="owner_type_cd"),targetElement=ChargebackOwnerType.class)
@Enumerated(EnumType.STRING)
@Sort(type=SortType.NATURAL)
private SortedMap<ChargebackOwnerType,Person> owners = new TreeMap<ChargebackOwnerType, Person>();
--
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, 3 months
[Hibernate-JIRA] Created: (HHH-2449) Lazy loading for one-to-one asociations
by jose (JIRA)
Lazy loading for one-to-one asociations
---------------------------------------
Key: HHH-2449
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2449
Project: Hibernate3
Type: New Feature
Components: core
Versions: 3.2.2
Environment: Hibernate 3.2.2
Reporter: jose
After read "Some explanations on lazy loading" and my tests I found a lossing feature in Hibernate (3.2.2).
one-to-one with lazy="proxy"_____________________________________________
Hibernate ALWAYS launch selects to know if one-to-one is null or can be proxied.
one-to-one with lazy="no-proxy"__________________________________________
Instrumentation allows to hibernate modify the getter to allows lazy loading on demand:
* but allways initialize ALL no-proxy relations (with first getter call)
-> must initialize ONLY the requested property
* never auto-initialize FETCH joins, ALWAYS doit on demand (if opened session)
-> must auto-initialize ONLY the FETCHED property
note: Can submit a fix for this? How?
NEW FEATURE: one-to-one with lazy="proxy" without multiple SELECTS______
If Hibernate adds join, for all one-to-one relations, to get the foreign-key of other tables, can check it to create a proxy or null.
note: that hibernate adds joins for hierarchy, why not for one-to-one relations?
This solution avoids:
* 'multiple subselects' after first select
* 'instrumentation' of bytecode
--
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, 3 months