November 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (ANN-858) implement @AttributeOverride for Map (key, value)

by Emmanuel Bernard (JIRA)

implement @AttributeOverride for Map (key, value) ------------------------------------------------- Key: ANN-858 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-858 Project: Hibernate Annotations Issue Type: Sub-task Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard -- 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

16 years, 3 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HV-227) hibernate validator message for turkish locale

by Firat KUCUK (JIRA)

hibernate validator message for turkish locale ---------------------------------------------- Key: HV-227 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-227 Project: Hibernate Validator Issue Type: Patch Affects Versions: 4.0.0.CR1 Reporter: Firat KUCUK Attachments: DefaultValidatorMessages_tr.properties validator.assertFalse=ifadesi hata döndürdü! validator.assertTrue=ifadesi hata döndürdü! validator.future=ileriki bir tarih olmalı! validator.length=uzunluğu {min} ve {max} arasında olmalıdır! validator.max={value} değerine eşit veya daha küçük olmalıdır! validator.min={value} değerine eşit veya daha büyük olmalıdır! validator.notNull=null değer alamaz! validator.past=geçmiş bir tarih olmalı! validator.pattern="{regex}" ifadesi ile örtüşmüyor! validator.range={min} ve {max} arasında olmalıdır! validator.size=boyut olarak {min} ve {max} arasında olmalıdır! validator.email=düzgün biçimli bir e-posta adresi değil! validator.notEmpty=null veya boş değer alamaz! validator.digits=numerik değil (<{integerDigits} digits>.<{fractionalDigits} digits> bekleniyor!) validator.creditCard=Geçerli kredi kartı numarası değil! validator.ean=Geçerli bir EAN değil! -- 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

16 years, 3 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HBX-902) Support naming / renaming HQL editor tabs

by Joseph Marques (JIRA)

Support naming / renaming HQL editor tabs ----------------------------------------- Key: HBX-902 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-902 Project: Hibernate Tools Type: New Feature Versions: 3.2beta8 Reporter: Joseph Marques Right now, if I open multiple HQL editors under the same configuration they are ALL named "HQL: <configuration>" When I have 3 or 4 of them open, I sometimes forget which query is in which, so I waste time poking around to find the right one. If they could be suffixed with the unique user-chosen token, then they would be much easier to work with. So something like: "HQL: <configuration>: <name>" Or, even better, since HQL isn't really needed (because the HQL editor has a distinct editor icon), it could be removed entirely, leaving us with: "<configuration>: <name>" Thoughts? -- 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

16 years, 3 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2399) FlushMode.AUTO practically unusable - should not flush before EVERY query

by Piotr Kołaczkowski (JIRA)

FlushMode.AUTO practically unusable - should not flush before EVERY query ------------------------------------------------------------------------- Key: HHH-2399 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2399 Project: Hibernate3 Type: Improvement Versions: 3.1.3, 3.2.1, 3.2.2, 3.2.0.ga Environment: PostgreSQL 8.1.5, JDBC 2 and 3, Linux kernel 2.4.x, 2.6.x, Java 1.5.0_09 Reporter: Piotr Kołaczkowski Attachments: hbtest.zip The method flushIfRequired seems to flush before every query execution, even though there wasn't anything changed to the objects in the session, and the objects in the session are of different class than the object(s) queried. When having more than a few such objects in a session, it may lead to large, unneeded overheads (I noticed 10-200 times slowdown on simple queries). Our system uses many fast queries, that uasually return only one result or few results. The average query durations on different levels, measured by System.nanoTime() (see the attachment): - database level: 0.05 ms - pure JDBC code, prepared statements: 0.2 ms - pure JDBC code, no prepared statements: 0.7 ms - not cached hibernate query, no other objects associated with the session: 1.3 ms - cached hibernate query, object in the session cache, no other objects associated with the session: 1.1 ms - cached hibernate query, 10000 very simple objects of some other class in the session: >50 ms 10000 may seem large, but note these were very simple objects, having only 2 properties. On our production system we have classes with many properties, and even 20 objects in a session can cause a sub-millisecond query to run longer than 5 ms. We switched to FlushMode.COMMIT, and now the performance is much better. Can you do something about this? As far as I've read in JIRA, a similar issue exists in Hibernate 2.x, and is still OPEN / UNRESOLVED. BTW. Why is the 1st level cache so slow in my tests? Why reading just a 2 field object from the database cause so much overhead over pure JDBC? What am I doing wrong? There is so much marketing about using cglib reflection optimizer in the performance FAQ but even if I retrieved these objects using JDBC and reflection, I would achieve much better performance. After all 1 ms is very much time, if getting results from DB and sending them to JVM lasts 0.2 ms. -- 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

16 years, 3 months

5
7
0 / 0

[Hibernate-JIRA] Created: (HHH-4531) Derby dialect should not support comments

by Chris Wilson (JIRA)

Derby dialect should not support comments ----------------------------------------- Key: HHH-4531 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4531 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.2 Environment: Derby 10.5.3.0, Linux Reporter: Chris Wilson Our mapping files contain column comments because they are supported on some of our databases. We use hbm2ddl to export the schema to each database. We are now adding support for Derby. Unfortunately Derby does not support column comments. I get errors like: ERROR SchemaExport: Unsuccessful: comment on column building_type.description is 'Site Building Type Description' ERROR SchemaExport: Syntax error: Encountered "comment" at line 1, column 1. I think that the DerbyDialect should return false for supportsCommentOn(). However it inherits from DB2Dialect which returns true for this property. Please add the following to DerbyDialect: public boolean supportsCommentOn() { return false; } -- 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

16 years, 3 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-2347) Improvement to DerbyDialect default identy generation mode

by Fabrizio Giustina (JIRA)

Improvement to DerbyDialect default identy generation mode ---------------------------------------------------------- Key: HHH-2347 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2347 Project: Hibernate3 Type: Patch Versions: 3.2.1 Reporter: Fabrizio Giustina Attachments: DerbyDialect-identity.diff although derby supports identities org.hibernate.dialect.DerbyDialect strangely uses an HiLo generation strategy for ids (for any other dialects that support identities IdentityGenerator is the default). Even more curiously, DerbyDialect overrides getIdentityColumnString() from the Db2 dialect by using "generated ALWAYS as identity" instead of "generated BY DEFAULT as identity". Derby however fully supports "by default" in identities as clarified in http://db.apache.org/derby/docs/10.1/ref/rrefsqlj37836.html . "by default" should be preferred since it allows a direct insertion when needed (and I can't see no reason why enabling it for db2 and not for derby). The patch attached simply deletes two methods, so that the default implementation from Db2Dialect is used: - removing getIdentityColumnString() make derby use "by default" identities like db2 already does - removing getNativeIdentifierGeneratorClass() make it choose IdentityGenerator.class (it falls back to the default strategy used in org.hibernate.dialect.Dialect) note that part of this issue has already been reported in HHH-1918 (not addressing the identity generation string) -- 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

16 years, 3 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-4574) ConnectionProviderFactory.getConnectionProperties() includes extra properties

by Kevin Bowman (JIRA)

ConnectionProviderFactory.getConnectionProperties() includes extra properties ------------------------------------------------------------------------------ Key: HHH-4574 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4574 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.4.sp1 Environment: Hibernate 3.2.4.sp1, Derby DB. Any Java environment where System properties include many properties whose names *include* 'hibernate.connection' but do not *start with* 'hibernate.connection'. Reporter: Kevin Bowman Attachments: org.hibernate.connection.ConnectionProviderFactory.patch, PropertiesTest.java In our environment we are setting a number of properties with keys like 'rpt.3.hibernate.connection.url'. They are used indirectly for configuring hibernate, but only a small fraction of them are used for configuring any given hibernate session. Unfortunately, all these System properties are being pulled into JDBC URL because of ConnectionProviderFactory, which causes problems like this with DerbyDB: 2009-11-13 09:57:19,065 [com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread-#1] WARN com.mchange.v2.resourcepool.BasicResourcePool - com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask@67f2b0dd -- Acquisition Attempt Failed!!! Clearing pending acquires. While trying to acquire a needed new resource, we failed to succeed more than the maximum number of allowed acquisition attempts (30). Last acquisition attempt exception: java.sql.SQLTransientConnectionException: A connection could not be established because the database name 'reports/lisa-reports.db;ction.password_enc=76f271db3661fd50082e68d4b953fbee;ction.username=sa;autocommit=false;ion.url=internal;create=true;ction.url=jdbc:derby://localhost:1527/db/reports.db;ction.driver_class=org.apache.derby.jdbc.ClientDriver' is larger than the maximum length allowed by the network protocol. at org.apache.derby.client.am.SQLExceptionFactory40.getSQLException(Unknown Source) at org.apache.derby.client.am.SqlException.getSQLException(Unknown Source) at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source) at com.mchange.v2.c3p0.DriverManagerDataSource.getConnection(DriverManagerDataSource.java:134) at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:182) at com.mchange.v2.c3p0.WrapperConnectionPoolDataSource.getPooledConnection(WrapperConnectionPoolDataSource.java:171) at com.mchange.v2.c3p0.impl.C3P0PooledConnectionPool$1PooledConnectionResourcePoolManager.acquireResource(C3P0PooledConnectionPool.java:137) at com.mchange.v2.resourcepool.BasicResourcePool.doAcquire(BasicResourcePool.java:1014) at com.mchange.v2.resourcepool.BasicResourcePool.access$800(BasicResourcePool.java:32) at com.mchange.v2.resourcepool.BasicResourcePool$AcquireTask.run(BasicResourcePool.java:1810) at com.mchange.v2.async.ThreadPoolAsynchronousRunner$PoolThread.run(ThreadPoolAsynchronousRunner.java:547) Caused by: org.apache.derby.client.am.SqlException: A connection could not be established because the database name 'reports/lisa-reports.db;ction.password_enc=76f271db3661fd50082e68d4b953fbee;ction.username=sa;autocommit=false;ion.url=internal;create=true;ction.url=jdbc:derby://localhost:1527/db/reports.db;ction.driver_class=org.apache.derby.jdbc.ClientDriver' is larger than the maximum length allowed by the network protocol. at org.apache.derby.client.net.NetConnectionRequest.buildRDBNAM(Unknown Source) at org.apache.derby.client.net.NetConnectionRequest.buildACCSEC(Unknown Source) at org.apache.derby.client.net.NetConnectionRequest.writeAccessSecurity(Unknown Source) at org.apache.derby.client.net.NetConnection.writeServerAttributesAndKeyExchange(Unknown Source) at org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown Source) at org.apache.derby.client.net.NetConnection.flowUSRIDPWDconnect(Unknown Source) at org.apache.derby.client.net.NetConnection.flowConnect(Unknown Source) at org.apache.derby.client.net.NetConnection.<init>(Unknown Source) at org.apache.derby.client.net.NetConnection40.<init>(Unknown Source) at org.apache.derby.client.net.ClientJDBCObjectFactoryImpl40.newNetConnection(Unknown Source) ... 9 more Attached is a test case and patch. -- 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

16 years, 3 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3391) DerbyDialect should support limits

by Marijo (JIRA)

DerbyDialect should support limits ---------------------------------- Key: HHH-3391 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3391 Project: Hibernate3 Issue Type: New Feature Components: core Environment: Apache Derby 10.4.1.3 Reporter: Marijo >From Apache Derby FAQ http://db.apache.org/derby/faq.html#limit "Starting with the 10.4.1.3 release Derby also supports limiting the number of rows using the ROW_NUMBER function." The DerbyDialect class should support limiting for the actual Derby release, too. -- 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

16 years, 3 months

3
2
0 / 0

[Hibernate-JIRA] Created: (ANN-797) using @LOB annotation

by Patrick Walter (JIRA)

using @LOB annotation --------------------- Key: ANN-797 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-797 Project: Hibernate Annotations Issue Type: Bug Reporter: Patrick Walter When I use the @LOB annotation it always creates only VARCHAR(255) for stringData and Binary (255) for binaryData defined below. @Lob @Basic(fetch=FetchType.LAZY) private byte[] binaryData; @Lob @Basic(fetch=FetchType.LAZY) private String stringData; Any help in resolving this would be VERRY!!! appreciated. THANKS -- 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

16 years, 3 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3555) Extend the query system with the ability to traverse associations

by Adam Warski (JIRA)

Extend the query system with the ability to traverse associations ----------------------------------------------------------------- Key: HHH-3555 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3555 Project: Hibernate Core Issue Type: New Feature Components: envers Reporter: Adam Warski Assignee: Adam Warski -- 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

16 years, 3 months

3
2
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 November 2009