December 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6504) Develop Map-style plural attribute support for new metamodel

by Steve Ebersole (JIRA)

Develop Map-style plural attribute support for new metamodel ------------------------------------------------------------ Key: HHH-6504 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6504 Project: Hibernate Core Issue Type: Task Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.next -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-6167) "Mixing nullable" Error Message Correction

by David (JIRA)

"Mixing nullable" Error Message Correction ------------------------------------------ Key: HHH-6167 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6167 Project: Hibernate Core Issue Type: Improvement Components: annotations, core Affects Versions: 3.6.1 Environment: Hibernate 3.6.1.FINAL Reporter: David Priority: Trivial I got the following exception: AnnotationException: Mixing nullable and non nullable columns in a property is not allowed: org.test.domain.PersonlastName Please consider changing it to: property is not allowed: org.test.domain.Person.lastName or property is not allowed: lastName of org.test.domain.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

12 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-821) Finalize SearchFactory API decisions

by Sanne Grinovero (JIRA)

Finalize SearchFactory API decisions ------------------------------------ Key: HSEARCH-821 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-821 Project: Hibernate Search Issue Type: Task Reporter: Sanne Grinovero Priority: Blocker When introducing HSEARCH-750 we created these methods: {code}org.hibernate.search.SearchFactory.openIndexReader(Class<?>...) org.hibernate.search.SearchFactory.closeIndexReader(IndexReader){code} An alternative idea would be to add a single indirection, as for example searchFactory.getReaderProvider().open / close This task is about taking a final decision on that matter, and review the SearchFactory API for other methods as well. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-495) Many locks on AnnotatedElements

by Loïc DIAS DA SILVA (JIRA)

Many locks on AnnotatedElements ------------------------------- Key: HV-495 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-495 Project: Hibernate Validator Issue Type: Patch Components: validators Affects Versions: 4.2.0.CR1 Environment: GNU/Linux, JVM 6.0, Hibernate Validator 4.2.0.CR1 Reporter: Loïc DIAS DA SILVA Attachments: jmeter-graph.docx, patch-ldds.patch Hi all, we use Hibernate Validator 4.2.0-CR1 (previously Apache BVAL) for one of our API projects. All is working fine for our needs except one big issue recently discovered during JMeter tests. Several injectors make many requests from some Amazon cloud servers to our API and starting from a number of requests the response time begins to increase eavily, making a big jump from about 100ms in average to more than 5s. After investigating we have seen many locks in some AnnotatedElement methods (mainly getAnnotation). I've then made a little patch on hibernate in order to cache this kind of requests as i've not found any other cleaver/yet implemented way.. Since this patch all is working very well for us.. Regards. -- 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, 5 months

3
13
0 / 0

[Hibernate-JIRA] Created: (HHH-6790) Add option to SequenceStyleGenerator to prefer a "sequence per entity"

by Steve Ebersole (JIRA)

Add option to SequenceStyleGenerator to prefer a "sequence per entity" ----------------------------------------------------------------------- Key: HHH-6790 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6790 Project: Hibernate Core Issue Type: New Feature Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.1.0 Basically this is a RFE for a corollary to {{org.hibernate.id.enhanced.TableGenerator#CONFIG_PREFER_SEGMENT_PER_ENTITY}} for the {{org.hibernate.id.enhanced.SequenceStyleGenerator}}. Currently, when no sequence name is given the default name (hibernate_sequence) is used. So this option would force {{org.hibernate.id.enhanced.SequenceStyleGenerator}} to determine a sequence name when none is explicitly given based on the name of the entity. The logic would be very similar to {{org.hibernate.id.enhanced.TableGenerator#determineDefaultSegmentValue}} but leveraging {{org.hibernate.id.IdentifierGenerator#ENTITY_NAME}} instead of {{org.hibernate.id.PersistentIdentifierGenerator#TABLE}} -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
2
0 / 0

[Hibernate-JIRA] Created: (BVAL-108) Implement a simpe performance test harness for Bean Validation

by Hardy Ferentschik (JIRA)

Implement a simpe performance test harness for Bean Validation -------------------------------------------------------------- Key: BVAL-108 URL: http://opensource.atlassian.com/projects/hibernate/browse/BVAL-108 Project: Bean Validation Issue Type: Task Components: ri-general Reporter: Hardy Ferentschik JPerf could for example be used. -- 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, 5 months

1
14
0 / 0

[Hibernate-JIRA] Created: (HHH-2614) Blob Length Set to 255 By Default With Derby DB

by Sean Sylvis (JIRA)

Blob Length Set to 255 By Default With Derby DB ----------------------------------------------- Key: HHH-2614 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2614 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.3 Environment: Apache Derby 10.2.2, Java 1.6.0 Reporter: Sean Sylvis When the (Hibernate) type "blob" is used in an object mapping file and a length is not specified, Hibernate converts this type as "blob (255)" to the Apache Derby database table definition. (This seems to be the same as the conversion behavior of a Java String to "varchar (255).") The same behavior results when using a CustomType that returns a Java SQL Types.BLOB. This is not the behavior I expected. Hibernate converts the same type as simply "blob" (which has a maximum length of 65535 bytes when no length is specified) when using MySQL version 5.0 (http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html). Furthermore, the Derby specification (http://db.apache.org/derby/docs/10.2/ref/rrefblob.html) states that a blob type without a length value will default to a length of 2M-1 bytes. I could not find a length specification for the Java SQL Blob type (http://java.sun.com/javase/6/docs/api/), but the current default length does seem to conform to other Hibernate type standards. That is, if a length is not specified, the length defaults to the maximum length defined for that type by the database. -- 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, 5 months

9
13
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-1018) Implement bridge that supports indexing for boolean queries based on lat and long instead of the whole grid

by Emmanuel Bernard (JIRA)

Implement bridge that supports indexing for boolean queries based on lat and long instead of the whole grid ----------------------------------------------------------------------------------------------------------- Key: HSEARCH-1018 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-1018 Project: Hibernate Search Issue Type: Sub-task Reporter: Emmanuel Bernard Assignee: Nicolas Helleringer This one should be trivial as it's a raw subset of what the current implementation does. We just need to make sure we use field names that are not polluted by HSSI thingies -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 5 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3240) In Derby field type 'text' is converted to CLOB(255)

by Aleksander Rozman (JIRA)

In Derby field type 'text' is converted to CLOB(255) ---------------------------------------------------- Key: HHH-3240 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3240 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.1 Environment: Hibernate 3.1, Derby 10.3.2.1 Reporter: Aleksander Rozman Priority: Blocker When using type 'text' this is incorectly converted to CLOB(255). Derby has several long var char types which could be used instead, but instead it's defaulted to clob(255). I have taken a look at source from 3.1 and 3.2.6 (latest) and this code is still the same... I think that just little fix in DerbyDialect would be enough... I would try this myself but I am currently lacking time and resources. I hope this will be taken care of as soon as it gets... -- 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, 5 months

7
25
0 / 0

[Hibernate-JIRA] Created: (HHH-5160) Error on binding values prepared statment in many-to-any relation

by wof (JIRA)

Error on binding values prepared statment in many-to-any relation ----------------------------------------------------------------- Key: HHH-5160 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5160 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1, 3.3.2 Environment: Tested on Version 3.3.2 and 3.5.1 on Oracle, PostgreSQL and MySQL Reporter: wof A Collection of Entities is defined as a ManyToAny relation, e.g. @ManyToAny(metaColumn=@Column(name="C_OBJECT_TYPE")) @AnyMetaDef(idType="string", metaType="string", metaValues={ @MetaValue(targetEntity=Entity1.class, value="Entity1"), @MetaValue(targetEntity=Entity2.class, value="Entity2") }) @JoinTable(name="T_OBJECTS", joinColumns=@JoinColumn(name="C_OWNER_ID"), inverseJoinColumns=@JoinColumn(name="C_OBJECT_ID") ) private Set<EntityBase> objects = new HashSet<EntityBase>(); Adding to this set works without problems. Removing all elements from the set (i.e. setting the set to null or zero-sized), too. However, when one or more elements are removed from the set with at least one element remaining, an exception is thrown: org.hibernate.exception.GenericJDBCException: could not delete collection rows with the cause being java.sql.SQLException: Parameter index out of range (3 > number of parameters, which is 2). I have narrowed this problem to this: The mapping table consists of 3 columns, C_OWNER_ID, C_OBJECT_TYPE and C_OBJECT_ID. The generated SQL-statement to delete the rows is as folling: DELETE FROM t_objects WHERE c_owner_id=? AND c_object_id=? However, Hibernate (in org.hibernate.typ.AnyType) tries to bind the actual value for c_object_id with index 3 which causes the exception. I guess Hibernate expects c_object_type to be present in the statement. As workaround we changed nullSafeSet in AnyType to: public void nullSafeSet(PreparedStatement st, Object value, int index, boolean[] settable, SessionImplementor session) throws HibernateException, SQLException { Serializable id; String entityName; if (value==null) { id=null; entityName=null; } else { entityName = session.bestGuessEntityName(value); id = ForeignKeys.getEntityIdentifierIfNotUnsaved(entityName, value, session); } // metaType is assumed to be single-column type // <ORIGINAL CODE> /* if ( settable==null || settable[0] ) { metaType.nullSafeSet(st, entityName, index, session); } if (settable==null) { identifierType.nullSafeSet(st, id, index+1, session); } else { boolean[] idsettable = new boolean[ settable.length-1 ]; System.arraycopy(settable, 1, idsettable, 0, idsettable.length); identifierType.nullSafeSet(st, id, index+1, idsettable, session); } */ // </ORIGINAL CODE> // <PATCHED CODE> if ( settable==null || settable[0] ) { metaType.nullSafeSet(st, entityName, index, session); boolean[] idsettable = new boolean[ settable.length-1 ]; System.arraycopy(settable, 1, idsettable, 0, idsettable.length); identifierType.nullSafeSet(st, id, index+1, idsettable, session); } else if (settable==null) { identifierType.nullSafeSet(st, id, index+1, session); } else { boolean[] idsettable = new boolean[ settable.length-1 ]; System.arraycopy(settable, 1, idsettable, 0, idsettable.length); identifierType.nullSafeSet(st, id, index, idsettable, session); } // </PATCHED CODE> } best regards wof -- 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, 5 months

3
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2011