Boolean types with MySQL 5
by Chris Long
Hello,
When I was previously using MySQL 4 and would create a boolean through
hibernate, it would create the boolean as a Tinyint. Now with MySQL 5, it's
creating it as a bit and causing my code to no longer work. I'm using the
wrapper class for Boolean in my Java POJO, Hibernate 3.2, Java 5, and MySQL
5.
How would I go about getting Hibernate to properly create the booleans as
tinyints?
Thanks,
Chris Long
17 years, 11 months
[Hibernate-JIRA] Updated: (HHH-1088) IdentifierProjection does not work with composite keys
by chris bono (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088?page=all ]
chris bono updated HHH-1088:
----------------------------
Attachment: CompositeIdProjection.java
I did not modify the core IdentifierProjection, but simply created another projection class. Ultimately these changes shoudl be integrated into IdentifierProjection.
1) getColumnAliases() modified to return the number of aliases that the component (composite key) is made up of.
2) toSqlString() properly generates commas in the list of aliases
> IdentifierProjection does not work with composite keys
> ------------------------------------------------------
>
> Key: HHH-1088
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088
> Project: Hibernate3
> Type: Bug
> Versions: 3.1 rc2
> Reporter: Max Muermann
> Priority: Minor
> Attachments: CompositeIdProjection.java, CriteriaLoader.java
>
>
> When working with Criteria queries, the IdentifierProjection breaks if the entity has a composite key.
> In IdentifierProjection.java:
> public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery)
> throws HibernateException {
> StringBuffer buf = new StringBuffer();
> String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> for ( int i=0; i<cols.length; i++ ) {
> buf.append( cols[i] )
> .append(" as y")
> .append(position + i)
> .append('_');
> }
> return buf.toString();
> }
> This method does not add commas as separators between the column names. Easily fixed by adding
> if (i<col.length-1)
> buf.append(",");
> as the last statement inside the loop.
> However, this leads to another problem:
> the type returned by IdentifierProjection.geType is the (single) type of the composite id component. The query will however return the property values of the id component without a mapping step.
--
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
17 years, 11 months
[Hibernate-JIRA] Updated: (HHH-1088) IdentifierProjection does not work with composite keys
by chris bono (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088?page=all ]
chris bono updated HHH-1088:
----------------------------
Attachment: CriteriaLoader.java
In getResultColumnOrRow() if the translator has a projection a component type is handled by consuming N column aliases rather than the very first one.
> IdentifierProjection does not work with composite keys
> ------------------------------------------------------
>
> Key: HHH-1088
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088
> Project: Hibernate3
> Type: Bug
> Versions: 3.1 rc2
> Reporter: Max Muermann
> Priority: Minor
> Attachments: CriteriaLoader.java
>
>
> When working with Criteria queries, the IdentifierProjection breaks if the entity has a composite key.
> In IdentifierProjection.java:
> public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery)
> throws HibernateException {
> StringBuffer buf = new StringBuffer();
> String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> for ( int i=0; i<cols.length; i++ ) {
> buf.append( cols[i] )
> .append(" as y")
> .append(position + i)
> .append('_');
> }
> return buf.toString();
> }
> This method does not add commas as separators between the column names. Easily fixed by adding
> if (i<col.length-1)
> buf.append(",");
> as the last statement inside the loop.
> However, this leads to another problem:
> the type returned by IdentifierProjection.geType is the (single) type of the composite id component. The query will however return the property values of the id component without a mapping step.
--
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
17 years, 11 months
[Hibernate-JIRA] Commented: (HHH-1088) IdentifierProjection does not work with composite keys
by chris bono (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088?page=c... ]
chris bono commented on HHH-1088:
---------------------------------
I have fixed this issue my slightly modifying the CriteriaLoader and IdentifierProjection classes. I will attach the specified files and if anyone wants to commit them, have at it. I simply do not have time to formally submit them but I still want to give the source back.
> IdentifierProjection does not work with composite keys
> ------------------------------------------------------
>
> Key: HHH-1088
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1088
> Project: Hibernate3
> Type: Bug
> Versions: 3.1 rc2
> Reporter: Max Muermann
> Priority: Minor
>
>
> When working with Criteria queries, the IdentifierProjection breaks if the entity has a composite key.
> In IdentifierProjection.java:
> public String toSqlString(Criteria criteria, int position, CriteriaQuery criteriaQuery)
> throws HibernateException {
> StringBuffer buf = new StringBuffer();
> String[] cols = criteriaQuery.getIdentifierColumns(criteria);
> for ( int i=0; i<cols.length; i++ ) {
> buf.append( cols[i] )
> .append(" as y")
> .append(position + i)
> .append('_');
> }
> return buf.toString();
> }
> This method does not add commas as separators between the column names. Easily fixed by adding
> if (i<col.length-1)
> buf.append(",");
> as the last statement inside the loop.
> However, this leads to another problem:
> the type returned by IdentifierProjection.geType is the (single) type of the composite id component. The query will however return the property values of the id component without a mapping step.
--
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
17 years, 11 months
[Hibernate-JIRA] Commented: (HHH-961) ConcurrentModificationException in Session.getEntityName()
by Andrew Redhead (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-961?page=co... ]
Andrew Redhead commented on HHH-961:
------------------------------------
I've just stumbled on this issue.
Using ejb3_rc9 in jboss 4.0.5.GA.
It looks like if you ask for the entity name of more than one uninitialised proxy for a sub-class in a session then you get the ConcurrentModificationException.
My code looks like:
List<MetEnt> metEntList = mtdtSvc.findMetEntsForAssetAtRevision(mtdt);
for (int uu = 0; uu < metEntList.size(); uu++) {
MetEnt metEnt = metEntList.get(uu);
JanesEnt jEnt = metEnt.getJanesEnt();
EntityManagerImpl mgrImpl = (EntityManagerImpl) em.getDelegate();
Session hbmSession = mgrImpl.getSession();
String entityName = hbmSession.getEntityName(jEnt);
}
Where metEntList is the result of running a named query amd jEnt could be any sub-type of JanesEnt.
The stack trace looks like:
java.util.ConcurrentModificationException
at org.apache.commons.collections.ReferenceMap$EntryIterator.checkMod(ReferenceMap.java:865)
at org.apache.commons.collections.ReferenceMap$EntryIterator.hasNext(ReferenceMap.java:840)
at java.util.AbstractMap.containsValue(AbstractMap.java:108)
at org.hibernate.engine.StatefulPersistenceContext.containsProxy(StatefulPersistenceContext.java:439)
at org.hibernate.impl.SessionImpl.getEntityName(SessionImpl.java:1737)
If I change the code to hand in an initialised entity then the problem goes away:
List<MetEnt> metEntList = mtdtSvc.findMetEntsForAssetAtRevision(mtdt);
for (int uu = 0; uu < metEntList.size(); uu++) {
MetEnt metEnt = metEntList.get(uu);
JanesEnt jEnt = metEnt.getJanesEnt();
jEnt = em.find(JanesEnt.class, jEnt.getId()); /* *** added line *** */
EntityManagerImpl mgrImpl = (EntityManagerImpl) em.getDelegate();
Session hbmSession = mgrImpl.getSession();
String entityName = hbmSession.getEntityName(jEnt);
}
> ConcurrentModificationException in Session.getEntityName()
> ----------------------------------------------------------
>
> Key: HHH-961
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-961
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.0.5
> Environment: Hibernate 3.0.5 running on JBoss 4.0.2 with JBoss' Hibernate integration, Database is Oracle 10g R1
> Reporter: Mathias Meyer
>
>
> I already posted this issue in the Hibernate forums and then tried, on Gavin's advice, to come up with a test case to reproduce the problem. I tried to reproduce this issue in a normal testcase, but didn't succeed with that until now. To not forget about posting this issue, I'm gonna post it anyway.
> Under certain circumstances I get a java.util.ConcurrentModificationException from SessionImpl.getEntityName(). It occures only, when I call getEntityName() on an entity that has just been loaded via Session.load(), and has lazy associations. As you can see in the stacktrace the exception occurs in PersistenceContext.containsProxy(), where the proxy checking and lazy-initializer-fetching happens. The problem seems to be that if the lazy association is being loaded during that call, which definitely seems to happen in my case, it modifies the PersistenceContext's proxiesByKey map. During the iteration the modification is being discovered and accordingly the exception is being thrown.
> The code involved is a lot, so I it's hard for me to separate the problem code from the rest, since there's a whole meta model around the code involved. What I can offer is a patch for the SessionImpl which definitely solved the problem for me. I ran the Hibernate test suites and all seemed to be well with it except the query- and ANTLR-involving ones which somehow don't want to work for me. The patch is inspired by the code in SessionImpl.getIdentifier() which does a similar thing. The following version of SessionImpl.getEntityName() seems to solve the problem:
> public String getEntityName(Object object) {
> if (object instanceof HibernateProxy) {
> LazyInitializer li = ((HibernateProxy) object).getHibernateLazyInitializer();
> if ( li.getSession() != this ) {
> throw new TransientObjectException( "The proxy was not associated with this session" );
> }
> object = li.getImplementation();
> }
> EntityEntry entry = persistenceContext.getEntry(object);
> if (entry==null) throwTransientObjectException(object);
> return entry.getPersister().getEntityName();
> }
> The stacktrace I get is as follows. FYI:
> java.util.ConcurrentModificationException
> at org.apache.commons.collections.ReferenceMap$EntryIterator.checkMod(Unknown Source)
> at org.apache.commons.collections.ReferenceMap$EntryIterator.hasNext(Unknown Source)
> at java.util.AbstractCollection.contains(AbstractCollection.java:99)
> at org.hibernate.engine.PersistenceContext.containsProxy(PersistenceContext.java:468)
> at org.hibernate.impl.SessionImpl.getEntityName(SessionImpl.java:1449)
> at de.asdis.acm.persistence.support.hibernate.HibernatePersistenceManager.getOid(HibernatePersistenceManager.java:116)
> at de.asdis.acm.persistence.support.hibernate.HibernatePersistenceManager.getObjectById(HibernatePersistenceManager.java:207)
> at de.asdis.acm.api.tools.SoftwareTools.findSoftwareBO(SoftwareTools.java:113)
> at de.asdis.acm.api.tools.SoftwareTools.createSoftwarePackage(SoftwareTools.java:499)
> at de.asdis.acm.api.ejb.ObjectManagerServiceBean.createSoftwarePackage(ObjectManagerServiceBean.java:497)
> at sun.reflect.GeneratedMethodAccessor382.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.invocation.Invocation.performCall(Invocation.java:345)
> at org.jboss.ejb.StatelessSessionContainer$ContainerInterceptor.invoke(StatelessSessionContainer.java:214)
> at org.jboss.resource.connectionmanager.CachedConnectionInterceptor.invoke(CachedConnectionInterceptor.java:185)
> at org.jboss.ejb.plugins.StatelessSessionInstanceInterceptor.invoke(StatelessSessionInstanceInterceptor.java:130)
> at org.jboss.webservice.server.ServiceEndpointInterceptor.invoke(ServiceEndpointInterceptor.java:51)
> at org.jboss.ejb.plugins.CallValidationInterceptor.invoke(CallValidationInterceptor.java:48)
> at org.jboss.ejb.plugins.AbstractTxInterceptor.invokeNext(AbstractTxInterceptor.java:105)
> at org.jboss.ejb.plugins.TxInterceptorCMT.runWithTransactions(TxInterceptorCMT.java:335)
> at org.jboss.ejb.plugins.TxInterceptorCMT.invoke(TxInterceptorCMT.java:166)
> at de.asdis.acm.interceptor.jboss.ApiExceptionInterceptor.invoke(ApiExceptionInterceptor.java:33)
> at org.jboss.ejb.plugins.SecurityInterceptor.invoke(SecurityInterceptor.java:139)
> at org.jboss.ejb.plugins.LogInterceptor.invoke(LogInterceptor.java:192)
> at org.jboss.ejb.plugins.ProxyFactoryFinderInterceptor.invoke(ProxyFactoryFinderInterceptor.java:122)
> at org.jboss.ejb.SessionContainer.internalInvoke(SessionContainer.java:624)
> at org.jboss.ejb.Container.invoke(Container.java:873)
> at sun.reflect.GeneratedMethodAccessor212.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
> at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
> at org.jboss.mx.server.Invocation.invoke(Invocation.java:72)
> at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:249)
> at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
> at org.jboss.invocation.jrmp.server.JRMPInvoker$MBeanServerAction.invoke(JRMPInvoker.java:805)
> at org.jboss.invocation.jrmp.server.JRMPInvoker.invoke(JRMPInvoker.java:406)
> at sun.reflect.GeneratedMethodAccessor211.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:261)
> at sun.rmi.transport.Transport$1.run(Transport.java:148)
> at java.security.AccessController.doPrivileged(Native Method)
> at sun.rmi.transport.Transport.serviceCall(Transport.java:144)
> at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
> at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
> at java.lang.Thread.run(Thread.java:534)
> I tried to reproduce this bug without the container, but haven't been able to do so yet. The fix works fine in our environment, where several thousand objects use this code during testing.
--
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
17 years, 11 months
