September 2011 - hibernate-issues

[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

12 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6645) Fix entity information

by Steve Ebersole (JIRA)

Fix entity information ---------------------- Key: HHH-6645 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6645 Project: Hibernate Core Issue Type: Bug Components: documentation Affects Versions: 4.0.0.CR2 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.CR3 /documentation/src/main/docbook/devguide/en-US/Hibernate_Development_Guide.ent -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6653) Clean up JAXB generated classes

by Steve Ebersole (JIRA)

Clean up JAXB generated classes ------------------------------- Key: HHH-6653 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6653 Project: Hibernate Core Issue Type: Improvement Components: documentation Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.CR3 The packaging really needs to be cleaned up and the naming too. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6640) Add ability for Integrator to prepare ServiceRegistryBuilder and MetadataImplementor as part of lifecycle

by Steve Ebersole (JIRA)

Add ability for Integrator to prepare ServiceRegistryBuilder and MetadataImplementor as part of lifecycle --------------------------------------------------------------------------------------------------------- Key: HHH-6640 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6640 Project: Hibernate Core Issue Type: Improvement Reporter: Steve Ebersole Assignee: Steve Ebersole 2 new, related capabilities: # The ability for an {{org.hibernate.integrator.spi.Integrator}} to prepare the {{org.hibernate.service.ServiceRegistryBuilder}}. The general idea here is to allow the {{org.hibernate.integrator.spi.Integrator}} to add both prepared services ({{org.hibernate.service.ServiceRegistryBuilder#addService}}) and ({{org.hibernate.service.ServiceRegistryBuilder#addInitiator}}). An additional use case could be to define alternate default settings via {{#applySetting}}, {{#applySettings}} and {{#configure}}. This call will most likely occur from the {{org.hibernate.service.ServiceRegistryBuilder}} constructor. # The ability to prepare Metadata. One example is overriding {{Type}} registrations. Both of these are "baselining" capabilities, meaning that they are defining baselines which explicit user calls, user supplied metadata, etc might override any work done here. See the following 2 IRC discussions for origins/thoughts: # http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/20... # http://transcripts.jboss.org/channel/irc.freenode.org/%23hibernate-dev/20... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

1
6
0 / 0

[Hibernate-JIRA] Created: (HHH-6635) C3P0: hibernate.c3p0.* configuration properties not properly parsed

by Guenther Demetz (JIRA)

C3P0: hibernate.c3p0.* configuration properties not properly parsed ------------------------------------------------------------------- Key: HHH-6635 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6635 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 4.0.0.CR2, 4.0.0.CR1 Reporter: Guenther Demetz Attachments: C3P0ConnectionProvider.java testing Hibernate4.0.0 CR 2 I discovered that unfortunately there is still a problem using C3P0 as ConnectionProvider: Though my patch provided with HHH-6327 made C3P0 work again, hibernate-c3p0 specific parameters such as hibernate.c3p0.max_size are not passed correctly to C3P0 anymore. The reason is that providing the patch for HHH-6327 I was not aware that the methods com.mchange.v2.c3p0.DataSources.java public static DataSource pooledDataSource( DataSource unpooledDataSource, Map overrideProps ) public static DataSource pooledDataSource( DataSource unpooledDataSource, Properties props ) are not processing the passed properties in the same way: whilst the first method parses the keyvalues as they are, the latter method peels the keyvalues by removing any "c3p0." prefix: public static DataSource pooledDataSource( DataSource unpooledDataSource, Properties props ) throws SQLException { //return pooledDataSource( unpooledDataSource, new PoolConfig( props ) ); Properties peeledProps = new Properties(); for (Iterator ii = props.keySet().iterator(); ii.hasNext(); ) { String propKey = (String) ii.next(); String propVal = props.getProperty( propKey ); String peeledKey = (propKey.startsWith("c3p0.") ? propKey.substring(5) : propKey ); peeledProps.put( peeledKey, propVal ); } return pooledDataSource( unpooledDataSource, null, peeledProps ); } The attached file does fix the problem. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-881) @Fields annotation calling getter multiple times

by adam (JIRA)

@Fields annotation calling getter multiple times ------------------------------------------------- Key: HSEARCH-881 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-881 Project: Hibernate Search Issue Type: Improvement Components: engine Affects Versions: 3.4.1.Final Environment: hibernate 3.6.6; postgres Reporter: adam Priority: Minor placing an @Fields annotation on a method appears to cause the method's getter to be called once for each @Field annotation inside the list. Depending on what's internal to the method, indexing speed may be optimized by setting the contents to a variable and thus only calling the method once. /* class snippit */ @Fields({ @Field(name = "allPhrase", analyzer = @Analyzer(impl = TdarStandardAnalyzer.class)), @Field(name = "all", analyzer = @Analyzer(impl = LowercaseWhiteSpaceStandardAnalyzer.class)) }) public String getKeywords() { logger.info("get keyword contents: {}",getId()); /* debug on save */ INFO 2011-08-29 10:37:30,828 12676 (Resource.java:982) org.tdar.core.bean.resource.Resource - get keyword contents: 4798 INFO 2011-08-29 10:37:30,828 12676 (Resource.java:982) org.tdar.core.bean.resource.Resource - get keyword contents: 4798 ... -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-912) JBoss Logger processor and generator is marked as a compile scope dependency

by Sanne Grinovero (JIRA)

JBoss Logger processor and generator is marked as a compile scope dependency ---------------------------------------------------------------------------- Key: HSEARCH-912 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-912 Project: Hibernate Search Issue Type: Bug Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.Beta1 It should be used only during compilation, so flagged as provided scope. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-911) Workspace implementors have to release IndexWriter on IO errors

by Sanne Grinovero (JIRA)

Workspace implementors have to release IndexWriter on IO errors --------------------------------------------------------------- Key: HSEARCH-911 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-911 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.Beta1 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-903) expose and IndexReader created by IndexManager names

by Sanne Grinovero (JIRA)

expose and IndexReader created by IndexManager names ---------------------------------------------------- Key: HSEARCH-903 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-903 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 4.0.0.Beta1 This is a requirement to give users more fine-grained options than opening an IndexReader on all shards for the specified entities: it's currently not possible to open such a reader on a shards subset. After a discussion on developer mailing list, we decided that this expert-level method should be exposed, and we can still expose an easier to use method in future versions. http://lists.jboss.org/pipermail/hibernate-dev/2011-September/007054.html -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-710) Add option to index fields using ANALYZED_NO_NORMS

by Sanne Grinovero (JIRA)

Add option to index fields using ANALYZED_NO_NORMS -------------------------------------------------- Key: HSEARCH-710 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-710 Project: Hibernate Search Issue Type: New Feature Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.4.0.Beta1 It seems it's currently not possible to use the indexing option org.apache.lucene.document.Field.Index.ANALYZED_NO_NORMS (workaround: use a custom fieldbridge) -- 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

12 years, 8 months

2
7
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues September 2011