IP banned from forum
by Gunnar Morling
Hi,
Is anyone banning users from the forum? I am getting "A ban has been
issued on your IP address."
I don't think banning by IP is a good strategy as many users will have
dynamic IPs from their hoster's shared pool, so it's a random game to
hit an IP previously banned due to some other user's spam.
Thanks,
--Gunnar
1 month, 2 weeks
New CI machine preview
by Sanne Grinovero
You're all welcome to play with http://54.225.162.168/
however please keep these in mind:
- it's not the final machine: don't put too much effort in creating
nice build scripts as we'll reset it to clean state soon. We *might*
be able to store jobs defined so far, but we might choose not to.
- domain name should be coming: ci.hibernate.org ..not sure when, got
no replies so far from.
- authentication: just click on login, it will use OAuth2 to request
your identity via your GitHub account. Permissions to create new jobs,
edit existing jobs, run a build manually depend on your github account
be part of the Hibernate organization (or not, in which case you have
read only status)
At this stage I'd like to get a feeling if the hardware is powerful
enough, and also we need to select which other plugins we want to use,
I'm looking especially to:
- static analysis reports
- pull requests integration
both are relatively undefined, we can of course start simple and
improve later.. just checking this fits basic needs now.
Sanne
4 months
6.0 - ResultTransformer
by Steve Ebersole
Another legacy concept I'd like to revisit as we move to 6.0 is the
Hibernate ResultTransformer. I'd argue that ResultTransformer is no longer
needed, especially in it's current form.
Specifically, ResultTransformer defines 2 distinct ways to transform the
results of a query:
1. `#transformTuple` - this method operates on each "row" of the result,
allowing the user to transform the Object[] into some other structure.
This is specifically the one I see no value in moving forward. Between
dynamic-instantiation, Tuple-handling, etc I think users have the needed
capabilities to transform the query result tuples.
2. `#transformList` - this one operates on the query result as a whole
(unless scroll/iterate are used). This method at least adds something that
cannot be done in another way. But I'd still personally question its
overall usefulness.
Does anyone have an argument for continuing to support either of these?
Personally, I propose just dropping the ResultTransformer support
altogether.
9 years, 1 month
Dialect#remapSqlTypeDescriptor
by Steve Ebersole
TLDR: Should we adjust to allow Dialect to know the "context" of where the
remapping is requested?
Ah Oracle...
So this comes from the fact that Oracle does not support a BOOLEAN
datatype. Well kind of. It does not support a BOOLEAN datatype in its
"SQL engine". However, in PL/SQL it does in fact support a BOOLEAN
datatype. Which comes into play when we talk about calling functions and
procedures: the arguments and returns can in fact be a BOOLEAN.
As far as I know, Oracle is the only database with this type of
inconsistency in its type system. But the question is whether we want to
pass along some kind of information regarding the context (SQL v function v
procedure) to the Dialect#remapSqlTypeDescriptor.
You can look at https://hibernate.atlassian.net/browse/HHH-11141 for an
illustration of how this impacts applications. And if you look through the
comments you can see the kind-of-crazy workaround needed.
9 years, 5 months
mixing named and positional parameters
by Steve Ebersole
The JPA spec specifically says:
<quote>
Either positional or named parameters may be used. Positional and named
parameters must not be mixed in a single query.
</quote>
I was thinking about how it does not make sense to mix these in a query
(its confusing) and went looking to see what, if anything, the spec had to
say on the subject. Which is when I found that passage.
Currently we do not validate this one way or the other. But I think we
ought to start. The only real question is whether to make this an
exception all the time, or just when strict-JPA-compliance is requested.
Personally I vote for always disallowing this (like I said, I find it
confusing), but would like to get other's thoughts.
9 years, 5 months
Starting 5.2.3 release
by andrea boriero
Due to troubles with my Nexus account the release is not yet completed
anyway It's now possible to push to master.
9 years, 5 months
Money Validation
by Willi Schönborn
Hi,
I'm currently preparing a pull request to contribute Java Money related
validators to HV:
https://github.com/zalando/money-validation
The main part are custom validators to add support for MonetaryAmount to
the following constraints:
- DecimalMax
- DecimalMin
- Max
- Min
As an addition we defined the following custom constraints:
- Negative
- NegativeOrZero
- Positive
- PositiveOrZero
- Zero
Their names are closely aligned to methods in MonetaryAmount, but they are
in fact built solely on top of the standard constraints DecimalMax and
DecimalMin. So in theory somebody can use those with int, longs,
BigDecimals, BigInteger, CharSequence, ... You get the idea.
My question now is, are you guys interested in those custom constraints as
well or should I limit my pull request to the validators for MonetaryAmount?
Best,
Willi
9 years, 5 months
ORM and Java 9
by Steve Ebersole
It seems like Shigeru and team have Javassist Java 9 compatible now. Per
https://issues.jboss.org/browse/JASSIST-261 I have played with the propsed
changes using a SNAPSHOT of that built and pushed by Scott. Using that
SNAPSHOT, all those tests which used to fail due to Javassist now pass.
We do still have some failures under Java 9 which are now all attributable
to the version of WildFly we use for some Arquillian-based testing not
being Java 9 compatible. But WildFly is now Java 9 compatible from what I
understand. Anyone know if there is a WildFly 10 release yet that is Java
9 compatible?
9 years, 5 months
