August 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-664) Create a mechanism to allow custom class and field bridges to specify analyzers for all fields added to document

by Hardy Ferentschik (JIRA)

Create a mechanism to allow custom class and field bridges to specify analyzers for all fields added to document ---------------------------------------------------------------------------------------------------------------- Key: HSEARCH-664 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-664 Project: Hibernate Search Issue Type: New Feature Components: engine Affects Versions: 3.3.0.Final Reporter: Hardy Ferentschik Currently there is no easy way to specify which analyzer to use for custom fields added via class or custom field bridges. One work around is to write/use a custom scoped analyzer and use it in conjunction which the bridge. Another work around is the use of _@ClassBridges_ with mutiple _@ClassBridge_. Using the query DSL one has to use _overridesForField_ to overcome the issue at query time. A more detailed discussion of the issue can be found on the Search forum - https://forum.hibernate.org/viewtopic.php?f=9&t=1008943&start=0 Possible solutions are: * Extension of bridge api * Introduction of a concept similar to _AnalyzerDiscriminator_ which only operates on field names. _AnalyzerDiscriminator_ depends on the entity state and is really only used during indexing. At search time this concept cannot be used, because there is no actual instance to pass to the query -- 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

14 years, 7 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-5968) Deprecate nullSafeGet()/nullSafeSet() methods with no SessionImplementor argument from UserType and AbstractSingleColumnStandardBasicType

by Gail Badner (JIRA)

Deprecate nullSafeGet()/nullSafeSet() methods with no SessionImplementor argument from UserType and AbstractSingleColumnStandardBasicType ----------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-5968 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5968 Project: Hibernate Core Issue Type: Deprecation Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.6.2 UserType.nullSafeGet() and nullSafeSet() methods will be deprecated because they do not take a SessionImplementor argument: public Object nullSafeGet(ResultSet rs, String[] names, Object owner) public void nullSafeSet(PreparedStatement st, Object value, int index) They will be replaced by methods taking a SessionImplementor argument in Hibernate 4. These new methods will not be added to UserType because doing so would break everyone's UserType implementation. In AbstractSingleColumnStandardBasicType, the following methods will be deprecated: public T nullSafeGet(ResultSet rs, String name) public Object get(ResultSet rs, String name) public void nullSafeSet(PreparedStatement st, T value, int index) public void set(PreparedStatement st, T value, int index) These methods should have been deprecated in AbstractSingleColumnStandardBasicType when their super methods in SingleColumnType were deprecated (the deprecation did not come across in Javadoc generated by {@inheritDoc}). The following methods should be used instead: AbstractSingleColumnStandardBasicType.nullSafeSet(PreparedStatement st, Object value, int index, boolean[] settable, SessionImplementor session) AbstractStandardBasicType.nullSafeGet(ResultSet rs, String name, SessionImplementor session, Object owner) -- 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

14 years, 7 months

5
9
0 / 0

[Hibernate-JIRA] Created: (HHH-3836) composite-element with null columns in map is ignored

by Benoit Goudreault-Emond (JIRA)

composite-element with null columns in map is ignored ----------------------------------------------------- Key: HHH-3836 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3836 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.0.SP1 Environment: 3.3.0 SP1, noticed with Oracle and H2 but probably happens with all databases Reporter: Benoit Goudreault-Emond Attachments: patate.zip When a composite element with all properties set to NULL is inserted in a map of the said composite element, the data gets inserted to the database but is never retreived when reloading the entity. For instance, with an entity @Entity public class TestEntity { @Id private int id; @CollectionOfElements private Map<String, AccessPeriod> roleAccesses = new HashMap<String, AccessPeriod>(); // boilerplate getters/setters/etc omitted } And AccessPeriod being @Embeddable public class AccessPeriod { public Date startDate; public Date endDate; } If you insert in the map an AccessPeriod with both startDate and endDate set to null and persist the TestEntity, an entry is inserted in the auxiliary table, but when getting the TestEntity back, the map is empty. You get the same problem with a mapping file. This used to work in Hibernate 2.1--I found this out while porting some code to 3.3. See the attached example. You'll need to include Hibernate and h2 (com.h2database:h2 1.0.20061217) on your classpath to run it with the given jdbc.properties, but feel free to change it. -- 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

14 years, 7 months

5
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5801) ColumnNameCache.columnNameToIndexCache map should be synchronized

by Ivan Popov (JIRA)

ColumnNameCache.columnNameToIndexCache map should be synchronized ----------------------------------------------------------------- Key: HHH-5801 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5801 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.2.7 Environment: AIX, IMB J9 jvm Reporter: Ivan Popov When I activate the result set wapper, hibernate.jdbc.wrap_result_sets=true, I can have a stacktrace such as : ####<Dec 15, 2010 8:44:27 PM CET> <Error> <WebLogicServer> <efa-bench> <decalog_server> <[ACTIVE] ExecuteThread: '29' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1292442267345> <BEA-000337> <[STUCK] ExecuteThread: '21' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "602" seconds working on the request "weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@73907390", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace: java.util.HashMap.findNonNullKeyEntry(HashMap.java:526) java.util.HashMap.getEntry(HashMap.java:510) java.util.HashMap.get(HashMap.java:496) org.hibernate.jdbc.ColumnNameCache.getIndexForColumnName(ColumnNameCache.java:52) org.hibernate.jdbc.ResultSetWrapper.findColumn(ResultSetWrapper.java:84) org.hibernate.jdbc.ResultSetWrapper.getString(ResultSetWrapper.java:248) org.hibernate.type.StringType.get(StringType.java:18) org.hibernate.type.NullableType.nullSafeGet(NullableType.java:163) org.hibernate.type.NullableType.nullSafeGet(NullableType.java:154) org.hibernate.type.AbstractType.hydrate(AbstractType.java:81) org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2091) org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1380) org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1308) org.hibernate.loader.Loader.getRow(Loader.java:1206) org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580) org.hibernate.loader.Loader.doQuery(Loader.java:701) org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) org.hibernate.loader.Loader.loadCollection(Loader.java:1998) org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36) org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565) org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:63) org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1717) org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) org.hibernate.collection.PersistentSet.size(PersistentSet.java:139) I think that columnNameToIndexCache map should be synchronized. I got the exception with 3.2.7 but I had a look at the latest version and the bug is still there. -- 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

14 years, 7 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HCANN-18) Make sure that the build enforces JDK 5 compilation just like Core does today

by Emmanuel Bernard (JIRA)

Make sure that the build enforces JDK 5 compilation just like Core does today ----------------------------------------------------------------------------- Key: HCANN-18 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-18 Project: Hibernate Commons Annotations Issue Type: Task Affects Versions: 3.2.0 Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- 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

14 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6439) Add Dialect.getAddUniqueConstraintString()

by Gail Badner (JIRA)

Add Dialect.getAddUniqueConstraintString() ------------------------------------------- Key: HHH-6439 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6439 Project: Hibernate Core Issue Type: Task Components: core Reporter: Gail Badner Fix For: 4.0.0.next Currently, Dialect.getAddPrimaryKeyConstraintString() is used for unique keys, then "primary key" is replaced by "unique". -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-6533) ByteTypeDescriptor is not working properly

by Čedomir Igaly (JIRA)

ByteTypeDescriptor is not working properly ------------------------------------------ Key: HHH-6533 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6533 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.6.6 Reporter: Čedomir Igaly Attachments: ByteTypeDescriptor.hbm.xml, ByteTypeDescriptorTest.java, Test.java Problem: ByteTypeDescriptor is not implemented like type descriptors for other subclasses of java.lang.Number. Instead of simple toString / valueOf pair it is using strange kind of conversion to hex character string. Here is just an example with named query that will convert HQL query from Test where byteValue=test.Test.TEST_VALUE into select id, byteValue from byte_type_descriptor_test where byteValue=aa (instead of select id, byteValue from byte_type_descriptor_test where byteValue=42) Since aa is treated like (non-existing) column name, this query will not work. Suggested solution: implement ByteTypeDescriptor like type descriptors for other java.lang.Number subclasses. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-6091) Let people customize identifier generator strategy mappings programmatically in Hibernate 4

by Emmanuel Bernard (JIRA)

Let people customize identifier generator strategy mappings programmatically in Hibernate 4 ------------------------------------------------------------------------------------------- Key: HHH-6091 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6091 Project: Hibernate Core Issue Type: New Feature Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard For OGM -- 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

14 years, 7 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6614) Bad performance: audited entity updates (lots of them) with no EntityManager clear

by Adriano Saturno Muniz (JIRA)

Bad performance: audited entity updates (lots of them) with no EntityManager clear ---------------------------------------------------------------------------------- Key: HHH-6614 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6614 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.6.6 Environment: Hibernate 3.6.6, Oracle Reporter: Adriano Saturno Muniz Attachments: src.zip I was testing Envers performance. I created an audited entity Mailmen, with a many-to-many relationship with another audited entyty, Address. Mailmen has a simple field called register. (and an Address collection, but lets simplify the code) I just created a new instance of Mailmen and edited it 100.000 times: configurationOverrides = new HashMap<String, String>(); emf = Persistence.createEntityManagerFactory("jpa", configurationOverrides); entityManager = emf.createEntityManager(); int MAX_EDITIONS = 1000000; carteiroDefault = new Mailman(); carteiroDefault.setRegister(64737); entityManager.persist(carteiroDefault); for(int i = 1; i <= MAX_EDITIONS; i++) { entityManager.getTransaction().begin(); carteiroDefault.setRegister(i); entityManager.getTransaction().commit(); } It tooks about 6 hours to run this code. It gets better or worse depending on MAX_EDITIONS, in a non linear way. Bad. But, if I change the for block to this: entityManager.getTransaction().begin(); entityManager.find(Mailman.class, carteiroDefault.getId()).setRegister(i); entityManager.getTransaction().commit(); entityManager.clear(); It tooks 30 minutes. It gets better or worse depending on MAX_EDITIONS, in a linear way. Much better. There's no bad performance without Envers in this scenario. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 7 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3318) Allow omitting varchar limit by default in PostgreSQL

by Luke Maurer (JIRA)

Allow omitting varchar limit by default in PostgreSQL ----------------------------------------------------- Key: HHH-3318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3318 Project: Hibernate3 Issue Type: New Feature Components: core Environment: Hibernate 3.2.6, PostgreSQL 8.3.1 Reporter: Luke Maurer Priority: Minor Essentially, what I'd like is for a String without a given maximum length be mapped as a varchar or text rather than a varchar(255) as is now the case. The maximum doesn't do anything to improve performance or storage efficiency in PostgreSQL, so varchar(255) merely imposes an arbitrary constraint. It would be more idiomatic to use varchar where no limit is given, leaving varchar(n) for cases where the length is limited as a business rule rather than an implementation detail. (Naturally, one can always use @Lob where it's actually *important* that the column be a varchar or text. So this is definitely minor.) -- 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

14 years, 7 months

2
1
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2011