October 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5625) Update Envers manual to reflect 'experimental' status of ValidityAuditStrategy and 'Revision-end-timestamp'

by Erik-Berndt Scheper (JIRA)

Update Envers manual to reflect 'experimental' status of ValidityAuditStrategy and 'Revision-end-timestamp' ------------------------------------------------------------------------------------------------------------ Key: HHH-5625 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5625 Project: Hibernate Core Issue Type: Task Components: envers Affects Versions: 3.6.0.CR2 Reporter: Erik-Berndt Scheper Assignee: Erik-Berndt Scheper Fix For: 3.6.x As discussed with Adam via IM: we should update the Envers manual to reflect the 'experimental' status of ValidityAuditStrategy and 'Revision-end-timestamp' -- 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, 7 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4453) Reserved keywords not quoted in table/column names

by Philipp Reichart (JIRA)

Reserved keywords not quoted in table/column names -------------------------------------------------- Key: HHH-4453 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4453 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: Hibernate 3.3.1 GA, Windows XP, Sun JDK 1.6.0_06, Derby 10.5 Reporter: Philipp Reichart I'm currently migrating our test suite form HSQLDB to Derby (we need transaction isolation and the HSLDB 1.9 RCs are no good), and found out that we have a lot of table or colum names that happen to be reserved keywords in Derby, like "transaction", "key", "value", "year", etc.. The usual workaround seems to be adding backticks to any offending table/column name in our hbm.xml files, but that's really an ugly workaround and doesn't prevent later incidents of this kind when new keywords show up in either our mappings or database. As this is about a production database schema, reanming the table/column names isn't an option either. I already tried implementing a custom Derby dialect and registering all the keywords from the Derby doc at http://db.apache.org/derby/docs/10.5/ref/rrefkeywords29722.html and even defined a "quote everything" NamingStrategy using the dialect to get the correct native quotes for the database. Unfortunately, neither the Hibernate DDL generator nor HQL queries seem to consider the naming strategy or dialect when handling table or column names. Is there any way to have Hibernate quote database-specific keywords every they're used? Or just have Hibernate quote everything that comes from a mapping file? -- 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, 7 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HV-358) Create a pluggable MessageInterpolator which can interploate ${value}

by Hardy Ferentschik (JIRA)

Create a pluggable MessageInterpolator which can interploate ${value} --------------------------------------------------------------------- Key: HV-358 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-358 Project: Hibernate Validator Issue Type: New Feature Components: engine Affects Versions: 4.1.0.Final Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.2.0 -- 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, 7 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3081) SQL queries do not currently support iteration

by MG (JIRA)

SQL queries do not currently support iteration ---------------------------------------------- Key: HHH-3081 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3081 Project: Hibernate3 Issue Type: Bug Reporter: MG Query sqlQuery = session.createSQLQuery("select * from TRADE").addEntity(Trade.class); sqlQuery.setReadOnly(true); sqlQuery.setCacheMode(CacheMode.IGNORE); sqlQuery.setCacheable(false); sqlQuery.setFetchSize(1000); Iterator<Trade> trades = sqlQuery.iterate(); Causes Exception in thread "main" java.lang.UnsupportedOperationException: SQL queries do not currently support iteration at org.hibernate.impl.SQLQueryImpl.iterate(SQLQueryImpl.java:190) -- 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, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2315) relax schemaupdate complaining about numeric/decimal

by Max Rydahl Andersen (JIRA)

relax schemaupdate complaining about numeric/decimal ---------------------------------------------------- Key: HHH-2315 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2315 Project: Hibernate3 Type: Improvement Components: core Reporter: Max Rydahl Andersen Fix For: 3.2.2 http://jira.jboss.com/jira/browse/JBSEAM-596 -- 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, 7 months

5
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3356) Support for subselect (subquery) in from clause

by Geoffrey De Smet (JIRA)

Support for subselect (subquery) in from clause ----------------------------------------------- Key: HHH-3356 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3356 Project: Hibernate3 Issue Type: New Feature Components: query-hql Reporter: Geoffrey De Smet Many databases support subselects in the from clause, for example: http://dev.mysql.com/doc/refman/5.0/en/unnamed-views.html And it's very handy. Native query's are sometimes a working workaround, but have many disadvantages, unlike HQL. Btw, I've searched through jira for over 20 minutes and didn't find an issue for this already. If there is one already, please give it a better title or link it to this issue :) -- 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, 7 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HV-353) Support inheritance for marker interfaces

by Marc Schipperheyn (JIRA)

Support inheritance for marker interfaces ----------------------------------------- Key: HV-353 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-353 Project: Hibernate Validator Issue Type: Improvement Components: annotation-processor Affects Versions: 4.1.0.Final Reporter: Marc Schipperheyn Assignee: Hardy Ferentschik Currently, constraints use marker interface specified in the group attribute to determine whether a constraint is active for a certain context. Unfortunately, group membership doesn't seem to support inheritance which would greatly reduce the number of markers required (and processing since you need less markers). E.g. (contrived) public interface CheckVehicle{} public interface CheckCar extends CheckVehicle{} public interface CheckBicycle extends CheckVehicle{} //bean @AssertTrue(groups={CheckVehicle.class}) Boolean workingBrakes() @NotNull(groups={CheckBicycle.class}) String brakeType() If the active group is CheckBicycle, it should validate both workingBrakes and brakeType. It should be a relatively simply change as well. -- 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, 7 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HV-374) NoSuchMethodError on Persistence.getPersistenceUtil() on WebLogic 10.3.3 (11g)

by Vitaly Polonetsky (JIRA)

NoSuchMethodError on Persistence.getPersistenceUtil() on WebLogic 10.3.3 (11g) ------------------------------------------------------------------------------ Key: HV-374 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-374 Project: Hibernate Validator Issue Type: Bug Affects Versions: 4.1.0.Final Environment: WebLogic 10.3.3 (11g) Reporter: Vitaly Polonetsky Assignee: Hardy Ferentschik The latest WebLogic comes with hybrid configuration of JPA 1.0 with some features of JPA 2.0: https://support.oracle.com/CSP/main/article?cmd=show&type=NOT&doctype=FAQ... This causes a problem with the way Hibernate Validator checks for existence of JPA 2.0: org.hibernate.validator.engine.resolver.DefaultTraversableResolver.detectJPA() checks for existance of javax.persistence.PersistenceUtil class (which exists only in JPA 2.0), but org.hibernate.validator.engine.resolver.JPATraversableResolver will not use it directly, instead it will use javax.persistence.Persistence.getPersistenceUtil() (the class exists for JPA 1.0, but the method is available only at JPA 2.0). This check is good for situations where either full JPA 1.0 or full 2.0 implementation is available, but is cases like we have in WebLogic it leads to an Error: java.lang.NoSuchMethodError: javax.persistence.Persistence.getPersistenceUtil()Ljavax/persistence/PersistenceUtil; at org.hibernate.validator.engine.resolver.JPATraversableResolver.isReachable(JPATraversableResolver.java:62) at org.hibernate.validator.engine.resolver.DefaultTraversableResolver.isReachable(DefaultTraversableResolver.java:94) at org.hibernate.validator.engine.resolver.SingleThreadCachedTraversableResolver.isReachable(SingleThreadCachedTraversableResolver.java:47) at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:757) at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:324) at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForRedefinedDefaultGroup(ValidatorImpl.java:273) at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:256) at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:210) at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:119) ... I would suggest a possible way to overcome this situation in Hibernate Validator: To check for existence of JPA 2.0, check the existence of Persistence.getPersistenceUtil() method, instead of checking for the existence of PersistenceUtil class. This will disable the use of JPA 2.0 features inside HV when the method is not available. -- 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, 7 months

2
11
0 / 0

[Hibernate-JIRA] Created: (HV-68) Consider reponening (see new patch)

by Lucien Weller (JIRA)

Consider reponening (see new patch) ----------------------------------- Key: HV-68 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-68 Project: Hibernate Validator Issue Type: Sub-task Reporter: Lucien Weller -- 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, 7 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5644) the list method should throw a exception when entity resource isn't add to Configuration class

by xu (JIRA)

the list method should throw a exception when entity resource isn't add to Configuration class ---------------------------------------------------------------------------------------------- Key: HHH-5644 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5644 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.2.0.ga Environment: hibernate version:3.2.0.ga database platform:Oracle9I Reporter: xu Attachments: test.rar Hi，I have get a problem in using the Hibernate framework, the hibernate version is 3.2.0. you can copy my unit test files into your project and run HibernateTest as a junit test application, the test result will be passed. But I think when the "Ya24" entity resource isn't add to Configuration, the list method at line 32 should throw a "org.hibernate.testmy.entity.Ya24dd is not mapped" exception, what do you think? ps. I found the same question at the latest version hibernate-distribution-3.6.0.CR2-dist.And running the test didn't need any database platform.Thank you. -- 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, 7 months

2
6
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2010