June 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3465) HiRDB Support

by Tomoto Shimizu Washio (JIRA)

HiRDB Support ------------- Key: HHH-3465 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3465 Project: Hibernate3 Issue Type: New Feature Components: core Affects Versions: 3.2.5 Environment: 3.2.5 + HiRDB V8 + Type4 JDBC Driver Reporter: Tomoto Shimizu Washio Attachments: hirdbdialect.patch I would like to contribute with a dialect for HiRDB, Hitachi's RDBMS. (For more information, please see http://www.hitachi.co.jp/Prod/comp/soft1/global/prod/hirdb/) I added 4 classes and slightly modified 2 existing classes as shown below. Please look at the documentation at the top of the patch for explanations. org.hibernate.dialect.HiRDBDialect (added) org.hibernate.dialect.UserFuncDeclParser (added) org.hibernate.dialect.DialectFactory (modified) org.hibernate.dialect.function.AnsiTrimEmulationFunction (modified) org.hibernate.dialect.function.AnsiTrimEmulationFunctionWithTrimstrs (added) org.hibernate.dialect.function.TypeQualifiedSQLFunction (added) You may think this code is relatively large as a dialect. It is because I also implemented user-defined function support. As HiRDB requires '?' parameters to be qualified by 'as <type>' in user-defined function invocations, I made a parser for the type declarations that the user specified in the properties file, and a renderer for the type qualifier. See javadoc comments of HiRDBDialect and UserFuncDeclParser for more details. This patch is created on Hibernate 3.2.5.ga and tested on HiRDB V8 with Type4 JDBC Driver. The example configuration for HiRDB is shown below: hibernate.dialect org.hibernate.dialect.HiRDBDialect hibernate.connection.driver_class JP.co.Hitachi.soft.HiRDB.JDBC.HiRDBDriver hibernate.connection.url jdbc:hitachi:hirdb://DBID=@HIRDBENVGRP=C:/hirdb.ini hibernate.connection.username hitachi hibernate.connection.password hitachi -- 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

11 years, 8 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-5554) Customise column aliasing scheme

by Chris Pheby (JIRA)

Customise column aliasing scheme -------------------------------- Key: HHH-5554 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5554 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.6.0.Beta4 Reporter: Chris Pheby Attachments: alias-patch.patch Currently, the column aliasing scheme is hardcoded in the method public String getAlias(Dialect dialect) of the Column class. Essentially, this constructs an alias by creating a prefix using any characters up to the first non-letter character in the column name. This is usually followed by '_' and a number for disambiguation. I am working with a legacy database where many columns share common prefixes such as 'CUS_', 'COL_'. These mean all the aliases end up being the same for many columns, making queries difficult to debug. This patch configures aliasing via Dialect, which was already being done for getMaxAliasLength(). This makes it possible to customise the behaviour by extending the Dialect being used. It does not otherwise change the standard behaviour. -- 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

11 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4079) Fail-fast a build using JDK6

by Andrew Lee Rubinger (JIRA)

Fail-fast a build using JDK6 ---------------------------- Key: HHH-4079 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4079 Project: Hibernate Core Issue Type: Improvement Environment: JDK6 Reporter: Andrew Lee Rubinger Attachments: HHH-4079.patch Emmanuel tells me that JDK5 is a requirement for building Hibernate Core. If JDK6 is an invalid choice, this patch will tell developers. -- 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

11 years, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3367) Add support to OpenEdge RDMS (Progress 10) in DialectFactory

by Glaucio Scheibel (JIRA)

Add support to OpenEdge RDMS (Progress 10) in DialectFactory ------------------------------------------------------------ Key: HHH-3367 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3367 Project: Hibernate3 Issue Type: Patch Components: core Affects Versions: 3.2.6 Reporter: Glaucio Scheibel Attachments: DialectFactory.java, DialectFactory.patch This patch adds OpenEdge (formely Progress Database) support to DialectFactory 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

11 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2654) Ingres dialect patch to support bit_length

by Chris Bredesen (JIRA)

Ingres dialect patch to support bit_length ------------------------------------------ Key: HHH-2654 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2654 Project: Hibernate3 Issue Type: Patch Components: core Reporter: Chris Bredesen Assignee: Steve Ebersole Priority: Minor Attachments: IngresDialect.diff This patch from Daniel fixes the Ingres dialect to support bit_length. -- 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

11 years, 8 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HV-296) Apply constraints on the elements of an Iterable instance

by Hardy Ferentschik (JIRA)

Apply constraints on the elements of an Iterable instance --------------------------------------------------------- Key: HV-296 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-296 Project: Hibernate Validator Issue Type: New Feature Components: engine Affects Versions: 4.0.2.GA Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik See BVAL-202 -- 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

11 years, 8 months

1
8
0 / 0

[Hibernate-JIRA] Created: (HV-501) Extend programmatic API to allow alteration of ConstraintValidator list for a given constraint

by Kevin Pollet (JIRA)

Extend programmatic API to allow alteration of ConstraintValidator list for a given constraint ---------------------------------------------------------------------------------------------- Key: HV-501 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-501 Project: Hibernate Validator Issue Type: New Feature Components: engine Reporter: Kevin Pollet Fix For: 4.3.0.next Currently it's only possible to alter {{ConstraintValidator}} list associated to a given constraint via XML mapping files (see http://people.redhat.com/~ebernard/validation/#xml-mapping-constraintdefi...). The programmatic API could provide a way to do this in a typesafe manner. If a programatic API is added in {{BV 1.1}} this functionality could also be addressed by the specification. Hibernate Validator forum post https://forum.hibernate.org/viewtopic.php?f=9&t=1011508 -- 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

11 years, 8 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HV-589) Consider keeping a constant placeholder instead of the full memory model for classes not indexed

by Emmanuel Bernard (JIRA)

Consider keeping a constant placeholder instead of the full memory model for classes not indexed ------------------------------------------------------------------------------------------------ Key: HV-589 URL: https://hibernate.onjira.com/browse/HV-589 Project: Hibernate Validator Issue Type: Improvement Components: engine Affects Versions: 4.3.0.Final Reporter: Emmanuel Bernard Andrej Golovnin wrote: > After updating JBoss 7 to use the Hibernate Validator 4.3.0 and > adding <property name="javax.persistence.validation.mode" value="NONE"/> > to our persistence.xml file I was able to reduce memory consumption > of SerializableValidatorFactory from ca. 90MB to ca. 256KB. :-) > What I was not able to do, is to avoid loading of Hibernate Validator > and Hibernate Envers at all as we don't use them. Emmanuel's reply If you do not use Hibernate Validator annotations, 90MB might indeed be too much :) Hardy, I wonder if we could optimize the memory model and JPA initialization so that we check if a class has constraints and if it does not, Hibernate Validator keeps a small placeholder to remember that but does not consume any other memory for this non validated class. We could save a lot instead of building the model and keeping it in memory. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

3
14
0 / 0

[Hibernate-JIRA] Created: (HV-467) Complete handling of default group sequence re-definitions for method validation

by Gunnar Morling (JIRA)

Complete handling of default group sequence re-definitions for method validation -------------------------------------------------------------------------------- Key: HV-467 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-467 Project: Hibernate Validator Issue Type: New Feature Components: engine Reporter: Gunnar Morling Fix For: 4.x In the context of method validation redefined default group sequences are currently considered only, when the evaluated bean type itself re-defines the default group sequences (so re-definitions up in the hierarchy are ignored). This behaviour should be aligned with the logic used for "standard" bean validation. -- 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

11 years, 8 months

3
19
0 / 0

[Hibernate-JIRA] Created: (HV-579) Investigate whether it makes sense to load meta data for method validation lazily

by Gunnar Morling (JIRA)

Investigate whether it makes sense to load meta data for method validation lazily --------------------------------------------------------------------------------- Key: HV-579 URL: https://hibernate.onjira.com/browse/HV-579 Project: Hibernate Validator Issue Type: Improvement Components: engine Affects Versions: 4.3.0.Beta1 Reporter: Gunnar Morling Fix For: 5.x Currently the entire meta data (bean as well as method validation related) is loaded upon validation. In order to increase runtime performance as well as to save memory, it might make sense to load method validation related meta data only in the method validation case. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

11 years, 8 months

2
1
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues June 2012