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
7 months, 3 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
10 months, 1 week
Preparing for 5.0.10 and 5.1.1 releases
by Gail Badner
I'm wrapping things up to release 5.0.10 and possibly 5.1.1 this weekend.
Please do not push any commits to 5.0 or 5.1 branches.
Thanks,
Gail
10 years
SchemaCreatorImpl always creating a poolable sequence
by Mark Rotteveel
I'm working on improving support for Firebird in Hibernate, and I have
run into a problem where
org.hibernate.tool.schema.internal.SchemaCreatorImpl is always trying to
create a pooled sequence.
Specifically:
applySqlStrings(
dialect.getCreateSequenceStrings(
jdbcEnvironment.getQualifiedObjectNameFormatter().format(
sequence.getName(), dialect ),
sequence.getInitialValue(),
sequence.getIncrementSize()
),
formatter,
options,
targets
);
With the default implementation this results in a
org.hibernate.MappingException: org.hibernate.dialect.FirebirdDialect
does not support pooled sequences (or at least: not by specifying it in
the DDL).
I'd like to know if I should just override
protected String getCreateSequenceString(String sequenceName, int
initialValue, int incrementSize)
and ignore the initialValue and incrementSize and just return the result
of getCreateSequenceString(sequenceName)
or if I should change the above code to call the deprecated(!) method
getCreateSequenceStrings(String sequenceName) is
supportsPooledSequences() is false:
dialect.supportsPooledSequences()
? dialect.getCreateSequenceStrings(
jdbcEnvironment.getQualifiedObjectNameFormatter().format(
sequence.getName(), dialect ),
sequence.getInitialValue(),
sequence.getIncrementSize()
) : dialect.getCreateSequenceStrings(
jdbcEnvironment.getQualifiedObjectNameFormatter().format(
sequence.getName(), dialect )
),
Kind regards,
Mark Rotteveel
--
Mark Rotteveel
10 years, 1 month
[OGM][HSEARCH] Hibernate OGM and Hibernate Search samples
by Flemming Harms
Folks,
Is there something similar to javaee7-samples for Hibernate OGM and HSEARCH
today? I know the Hibernate Demo repo exist, but from what I can read this
is demos you have created for various talk and presentations.
If not I would suggest a new repository is created with samples showing how
to use OGM, HSEARCH in various ways and configurations. The Hibernate Demo
repo could be a good starting point, but I’m thinking a new repo where we
divide into modules to make it easy to upgrade and maintain the samples
from a parent configuration file etc.
I personally learn much more from examples and then I can use the
documentation as reference point. And this will also be good reference
repository for testing against when releasing a new version.
I would like to contribute with various samples to help build the repository
What do you think?
/Flemming
10 years, 1 month
Re: [hibernate-dev] People can't find our docs
by Guillaume Smet
Hi Sanne,
Thanks for your feedback. I was pretty sure I hadn't all the history!
Getting Google to prioritize our latest doc is probably a long time goal.
I played a bit with jQuery to suggest to the user to go to the latest
stable. Note that I only took into consideration the page for the time
being and didn't consider the anchor but it should be easy to add it
if we think it's worth it (it's a lot more work on the json descriptor
though).
The following command for each version is all that is needed:
sed -i 's@</body>@<script
src="http://code.jquery.com/jquery-3.1.0.min.js"
integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
crossorigin="anonymous"></script><script
src="/hibernate/search/outdated-version.js"></script></body>@' *.html
(or a find -exec to do it on all the versions at once)
I attached the global json descriptor and the js file (with a .txt
extension as it didn't pass the mail filter). Both should be added to
/hibernate/search/. Note that I only did the work for version 4.5 in
the json descriptor. The work for other versions would mostly be a
copy/paste.
I also attached a screenshot of how it looks like. Nothing fancy but
we can do whatever we want.
Note that I only targeted the multi page HTML output as it was the
most interesting to prototype.
When we release a new version, we would have to update the descriptor file.
Comments?
--
Guillaume
On Tue, Jul 19, 2016 at 2:39 PM, Sanne Grinovero <sanne(a)hibernate.org> wrote:
> Hi Guillaume,
>
> yes I'm aware of the issue; we discussed it before, I think on this
> same mailing list but maybe it was during our last meeting.
>
> We really need to fix that metadata; Stefania (my partner) is an SEO
> consultant and is shocked at how bad we do with this; apparently we
> are a funny example in her office but at least we're not the worst :)
>
> The problem is we can't change the headers as we don't control the
> Apache httpd configuraion on the documentation server, so the
> alternative is we'd need to rsync those docs locally, insert the right
> changes in the static files of the docs, and push them back.
>
> Needs a volunteer to find some time for this.
>
> Also related to SEO I recently opened some issues on our WEBSITE
> project, these should be easier to fix as it's directly under our
> control:
> - https://hibernate.atlassian.net/browse/WEBSITE-461
> - https://hibernate.atlassian.net/browse/WEBSITE-460
> - https://hibernate.atlassian.net/browse/WEBSITE-459
>
> I've assigned them to Davide as he's usually quick with such things
> but anyone is welcome to take some.
>
> The metadata issue on the docs server is probably the most urgent /
> valuable though.
>
> Thanks,
> Sanne
10 years, 1 month
multiLoad support
by Steve Ebersole
I wanted to start a consolidated discussion about multi-load support. This
relates to a few Jiras, questioning a few different aspects of its current
behavior:
https://hibernate.atlassian.net/browse/HHH-10984
https://hibernate.atlassian.net/browse/HHH-10617
Basically this comes down to the following questions/requests...
## Handling locally deleted entities
First (from HHH-10984) is the idea that locally deleted entities are
currently returned from multi-load calls. The background here is that
multi-load support was designed based on IdentifierLoadAccess#getReference
(Session#load). So its outcome follows what is done for #getReference in
terms of behavior and results. Now one of the behaviors of #getReference
that differs from IdentifierLoadAccess#load (Session#get) is how locally
deleted entities are treated: #getReference will return them, whereas #load
will not.
So as I see it we have 3 options:
1. Continue to expose just the one form on MultiIdentifierLoadAccess and
either have this filter out the locally deleted objects, or add a new
option to specify whether locally deleted objects ought to be returned in
the results.
2. Expose 2 distinct forms on MultiIdentifierLoadAccess:
1. Plural form of #getReference (current behavior, more or less)
2. Plural form of #load
3. Expose 3 distinct forms on MultiIdentifierLoadAccess:
1. Plural form of #getReference
2. Plural form of #load
3. "Hybrid" form
## Ordering of results
Much of the discussion on HHH-10984 revolves around the (poorly based, imo)
assumption that because a List/array of ids is passed in and because a List
is returned that we ought to return the results in the order indicated by
the incoming List/array of ids.
While I do not agree with the assumption there, I can see that that
behavior might sometimes be beneficial. Is this something we want to
support? There is certainly a performance overhead, and so I think we
definitely do not want to support it by default. But do we want to expose
an option to allow users to request this?
10 years, 1 month
