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?
15 years
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.
15 years
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
15 years
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
15 years
[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
15 years
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
15 years
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.
15 years
