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
9 years, 1 month
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
9 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
9 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
9 years, 2 months
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?
9 years, 2 months
Re: [hibernate-dev] multiLoad support
by andrea boriero
On 25 Jul 2016 19:29, "Steve Ebersole" <steve(a)hibernate.org> wrote:
>
> 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
>
>
I am inclined towards the 2 plural forms
> ## 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?
>
+1 for exposing an option for ordering the results
_______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
9 years, 2 months
