March 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3827) Properties accessed using a PropertyAccessor are not persisted in the AuditTable.

by Kaizer (JIRA)

Properties accessed using a PropertyAccessor are not persisted in the AuditTable. --------------------------------------------------------------------------------- Key: HHH-3827 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3827 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.3.1 Environment: Hibernate version 3.3.1. Database - Oracle10g Reporter: Kaizer Attachments: property_accessor_testcase.patch I have certain properties which will be accessed using a PropertyAccessor. However, these properties are not persisted in the AuditTable. I had a look at the AuditPropertiesReader class and the addFromProperties method is called for "field" and "property" but not for accessors. Perhaps this could be the cause. Please have a look at the attached path which contains a crude test case to reproduce the same. It throws an exception saying the column itself cannot be found. Forum discussion - http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4220283 -- 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

15 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (ANN-354) @javax.persistence.SequenceGenerator defaults to 'seqhilo' strategy.

by Andrew Pitt (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-354?page=co... ] Andrew Pitt commented on ANN-354: --------------------------------- I agree this is not a bug, but I also agree that the solution is less than ideal. With so much of hibernate being configurable, I'm surprised the hilo generator would be hard coded in. Adding "allocationSize=1" to your annotations is fine if you have one or two, but a maintenance pain if you have many. If the hilo generator is going to be forced on developers, it would be nice to at least be able to alter the allocationSize in the config, so that there's only ONE place to maintain this value. - Andrew > @javax.persistence.SequenceGenerator defaults to 'seqhilo' strategy. > -------------------------------------------------------------------- > > Key: ANN-354 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-354 > Project: Hibernate Annotations > Issue Type: Improvement > Affects Versions: 3.2.0.cr1 > Reporter: Andrey Petrov > > When using an oracle-style sequence to auto generate primary key values like this: > @Id > @GeneratedValue(strategy=GenerationType.SEQUENCE, generator="MySeq") > @SequenceGenerator(name="MySeq", sequenceName="ORACLE_SEQ") > public long getId() { > return id; > } > then a org.hibernate.id.SequenceHiLoGenerator is always used. > There should be a way to configure a different generator! > Since the hilo generator is not suitable for my application I have to use this instead: > @Id > @GeneratedValue(generator="MySeq") > @GenericGenerator( > //this is a hibernate-specific hack to force the use of a regular sequence generator > //otherwise a sequencehilo generator is used by default :-((( > name = "MySeq", strategy = "sequence", parameters = { > @Parameter(name = "sequence", value = "ORACLE_SEQ") > } > ) > public long getId() { > return id; > } > Now this works fine and while this solution can be tolerated for my app I really wish there was another way to control the default generator strategy (sequencehilo or plain sequence) without resorting to hibernate-specific org.hibernate.annotations.GenericGenerator annotations. > Do you think a mechanism for configuring that can be added to a future hibernate annotations version? > p.s. > as long as i can see the seqhilo generation strategy is hardcoded in: > org.hibernate.cfg.AnnotationBinder.java:1925: case SEQUENCE: > org.hibernate.cfg.AnnotationBinder.java:1926: return "seqhilo"; > (in hibernate annotations version 3.2.0.cr1) -- 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

15 years, 2 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HCANN-5) Decouple the reflection work from the metadata overriding facility

by Emmanuel Bernard (JIRA)

Decouple the reflection work from the metadata overriding facility ------------------------------------------------------------------ Key: HCANN-5 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-5 Project: Hibernate Commons Annotations Issue Type: New Feature Reporter: Emmanuel Bernard Fix For: 3.2 Introducing the notion of MetadataProvider -- 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

15 years, 2 months

1
1
0 / 0

[Hibernate-JIRA] Created: (ANN-810) Use the new MetadataProvider facility to implement EJB3 overriding

by Emmanuel Bernard (JIRA)

Use the new MetadataProvider facility to implement EJB3 overriding ------------------------------------------------------------------ Key: ANN-810 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-810 Project: Hibernate Annotations Issue Type: Improvement Components: binder Reporter: Emmanuel Bernard Fix For: 3.5 -- 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

15 years, 2 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-301) Refactor JMSMasterTest and JMSSlaveTest

by Hardy Ferentschik (JIRA)

Refactor JMSMasterTest and JMSSlaveTest --------------------------------------- Key: HSEARCH-301 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-301 Project: Hibernate Search Issue Type: Improvement Components: build Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik The aim is to get rid of the embedded jboss server for the test. This environment is not supported and creates amongst others problems with CP builds. The embedded server is only used for testing the JMS clustering functionality. This functionality could be replaced with ActiveMQ - http://activemq.apache.org/how-to-unit-test-jms-code.html. -- 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

15 years, 2 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-332) documentation error p.11: org.hibernate.Query should be javax.persistence.Query

by Yev Belman (JIRA)

documentation error p.11: org.hibernate.Query should be javax.persistence.Query --------------------------------------------------------------------------------- Key: HSEARCH-332 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-332 Project: Hibernate Search Issue Type: Bug Components: documentation Affects Versions: 3.1.0.GA Environment: Core 3.3.1.GA Search 3.1.0.GA Reporter: Yev Belman JPA example on page 11 is wrong: // wrap Lucene query in a org.hibernate.Query org.hibernate.Query hibQuery = fullTextEntityManager.createFullTextQuery(query, Book.class); It should read: javax.persistence.Query hibQuery = fullTextEntityManager.createFullTextQuery(query, Book.class); -- 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

15 years, 2 months

3
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-326) Drop support for IndexReader usage to update indexes.

by Sanne Grinovero (JIRA)

Drop support for IndexReader usage to update indexes. ----------------------------------------------------- Key: HSEARCH-326 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-326 Project: Hibernate Search Issue Type: Task Components: engine Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.1.1 in Workspace, remove "getIndexReader()" and all references to an IndexReader. In LuceneWorkDelegate and all implementations, remove "performWork(LuceneWork work, IndexReader reader)" Simplify PerDPQueueProcessor as no "best strategy choice" makes sense anymore. -- 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

15 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-345) Use any custom LockFactory

by Sanne Grinovero (JIRA)

Use any custom LockFactory -------------------------- Key: HSEARCH-345 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-345 Project: Hibernate Search Issue Type: New Feature Components: directory provider Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 3.1.1 more flexibility for HSEARCH-284: as Emmanuel asked to be able to use *any* LockFactory using the fqn of a factory defined in configuration, additionally to simple names. -- 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

15 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-284) Lucene locks left around in application restart/crash

by sam doyle (JIRA)

Lucene locks left around in application restart/crash ----------------------------------------------------- Key: HSEARCH-284 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-284 Project: Hibernate Search Issue Type: Improvement Affects Versions: 3.0.1.GA Reporter: sam doyle In a case where an application restarts, crashes, gets killed etc. if there is an existing Lucene lock it will not be removed on the application restart. As a result of this the application itself can be severely impacted. After encountering this particular issue and needing to manually remove the lock to resolve the problem I did some searching. It appears this situation is somewhat common and the use of NativeFSLockFactory was the suggested solution. Since I don't see where this particular option is configurable with Hibernate Search I have opened this request. -- 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

15 years, 2 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3822) mysql lack of timestamps with milliseconds breaks hibernate when used with versioning

by Thomas Hartwig (JIRA)

mysql lack of timestamps with milliseconds breaks hibernate when used with versioning ------------------------------------------------------------------------------------- Key: HHH-3822 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3822 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.3.1 Environment: mysql-5.1.32-1.fc10 Java(TM) SE Runtime Environment (build 1.6.0_12-b04) Reporter: Thomas Hartwig When I persist an instance with saveOrUpdate into a mysql dbms a version field is kept in milliseconds precision in the current application context. Unfortunately mysql truncates all the milliseconds from this field. So a following merge or any other version based operation fails until the object is refetched. Possible workarounds: - use an interceptor for truncating the version field - avoid using timestamp of mysql I know the milliseconds problem is really annoying by mysql and it is not a hibernate fault, but probably it can be avoided somehow or hibernate should throw an unsupported exception. Below is the sample setup: @Entity @Table(cname = "_Column") public class MappedColumn implements Serializable { private Date mtime; @Version public Date getMtime() { return mtime; } public void setMtime(Date mtime) { this.mtime = mtime; } [...] } CREATE TABLE `_Column` ( `name` varchar(255) collate latin1_german1_ci NOT NULL, `booleanColumn` bit(1) NOT NULL default '\0', `id` varchar(255) collate latin1_german1_ci NOT NULL default '', `ctime` datetime default NULL, `mtime` datetime default NULL, `columnOsc` varchar(255) collate latin1_german1_ci default NULL, `columnDbr` int(11) default NULL, PRIMARY KEY (`id`), UNIQUE KEY `name` (`name`) ) ENGINE=InnoDB DEFAULT CHARSET=latin1 COLLATE=latin1_german1_ci; -- 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

15 years, 2 months

1
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2009