July 2011 - hibernate-dev - Jboss List Archives

save the planet one non character stroke at a time

by Emmanuel Bernard

Today for pull requests, we do push to a branch named after the JIRA issue eg 'git push manu HSEARCH-123' I propose that for issues related to the project (99.9% of the time), we instead use the numeric part of the issue as a branch name eg 'git push manu 123' As Git repos are naturally scoped to the issues, that should not be a problem and it will help type less and help git-complete auto completion. Anyone against?

14 years, 11 months

4
8
0 / 0

Use of local time for @Version on Oracle and Customisation of Column Alias Scheme

by Chris Pheby

Hi I have newly subscribed to this list. Some time ago I submitted patches to the Hibernate Jira to address a couple of issues. https://hibernate.onjira.com/browse/HHH-5553 The first is the use of local time for the @Version field and suggest using the UTC function instead on Oracle https://hibernate.onjira.com/browse/HHH-5554 The second relates to providing a mechanism for customising the column aliasing scheme. This is due to widespread use of '_' in identifiers on Oracle which is also used as a truncation marker by Hibernate making generated queries difficult to read. Is there any interest in applying either of these two fixes, if so, I can update them for the current Hibernate 4.0.0 codebase if necessary. With thanks, Chris

14 years, 11 months

1
0
0 / 0

Deprecating or removing entirely HashtableCacheProvider?

by Emmanuel Bernard

I always die a little when I see someone using HashtableCacheProvider. What do you think of removing it entirely. Worse case, we could provide an implementation that is backed by ConcurrentHashMap but even with that, we would get no eviction policy etc.

14 years, 11 months

6
24
0 / 0

Bean Validation 1.1 on review ballot

by Emmanuel Bernard

http://jcp.org/en/jsr/detail?id=349 :)

14 years, 11 months

2
1
0 / 0

MethodLevel Constraints for method level validations

by Emmanuel Bernard

Do you think we should support the following? @DateInOrder void bookHotel(@NotNull @Valid Customer customer, Date from, Date to); ie like we have properly level and class level constraints, we could get method level constraints receiving all the parameters and raising constraints violations if necessary. Emmanuel

14 years, 11 months

5
8
0 / 0

Search: logged warnings annoying for Infinispan ISPN-1218

by Sanne Grinovero

Hello, ISPN-1218 is about users complaining that the embedded Hibernate Search is logging warnings about being used out of transaction. I'm not sure if we should really mandate this to be running transaction in the context of Infinispan. I think that there might be valid use cases in the case of Infinispan/Query in which there is no transaction; this warning was added because otherwise when running in the context of Hibernate we might be loading collections during flush, and a "pre-flush" listener was created to work around this case, but this doesn't apply to Infinispan. So my idea was to add an "spi-level" configuration property which would disable this warning. Any better ideas? Or would it be a better idea to make sure it's bound to the TM in that case too? Regards, Sanne

14 years, 11 months

2
1
0 / 0

[Search] supporting a 3.4.x branch?

by Sanne Grinovero

While I'm not very enthusiastic on backporting all fixes to a 3.4.x branch as the code is diverging significantly, I'm creating the branch at least, to make the option available to evaluate backporting on a per-case basis, especially if anybody volunteers to pick & port the commit. I'm going to apply HSEARCH-744 on such a branch as it was nicely fixed by Mathieu Perez, and it was flagged for a fix in 3.4.1. Sanne

14 years, 11 months

1
0
0 / 0

Feedback on Bean Validation JAX-RS integration

by Emmanuel Bernard

http://java.net/projects/jax-rs-spec/pages/Validation Can you guys have a look at it a give me your feedback. The JAX-RS expert group has created this draft and looks for feedback.

14 years, 11 months

3
6
0 / 0

Search: to follow or not to follow latest Lucene index format

by Sanne Grinovero

So the testsuite is using an helper method "org.hibernate.search.test.SearchTestCase.getTargetLuceneVersion()" for all those cases in which the unfriendly Lucene API demands a version. The test method is currently returning this constant: Version.LUCENE_31 The ConfigContext is using a default of Version.LUCENE_30 if the user doesn't specify any version in the configuration. ..and I recently updated the Lucene dependency to 3.3, without changing these values. Now if we really want to keep them in sync, we could use Version.LUCENE_CURRENT; but this is deprecated, not because it's going to be removed but because there are implications in using it, so it's discouraged. It's also nice to be able to verify compatibility of Search's use of Lucene when using a backwards compatible index format. I think we're not tracking the latest version of Lucene with this flag, because we wanted to make sure we where backwards compatible. Given we're now having the option to break backwards compatibility, should we start tracking the latest version of Lucene, and log a warning if the configuration value is not set? As the Lucene developers suggest, we should recommend coding this value in the configuration. Also because Hibernate Search now seems to work equally well with all Lucene 3.0.x, 3.1.x and 3.3.x, we should either consider only the latest supported, or test for the others too: worth having an environment parameter to be able to run the testsuite with older Lucene versions, or run it in mixed environments of newer Lucene versions but configured as older versions? Cheers, Sanne

14 years, 11 months

2
2
0 / 0

Still true with Javassist? Any final method prevents Hibernate from creating single-ended association proxies

by Robin Sander

Hi all, excuse me if this list isn't indented for such a question, but I asked this question about a year ago in the forums without any answers and I think it should be easy to answer for any Hibernate core developer: According to Hibernate's (3.6.5) reference documentaion (Section 21.1.3, Single-ended association proxies), such a single-ended association proxy can't be constructed by Hibernate if it contains "any final methods". My question is, does this restriction apply to getters/setters of persistent fields only or really to any method in an entity class? As far as I can see Javassist is able to modify final methods as well and even if it were not, why should a method like public final String toString() { return "..."; } prevent Hibernate from using a proxy? Thanks in advance, Robin.

14 years, 11 months

2
6
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-dev July 2011