> I think we should just change the behavior of calling EMF#close on a closed
EMF.
> Any application that happens to be relying on us no-op'ing
> this call can easily change that to protect the call with an `#isOpen`
check.
Mentioning this just in case: the javadoc for the AutoCloseable interface
On 24 November 2017 at 17:39, Steve Ebersole wrote:
> Andrea, SF is a EMF. Unwrapping simply returns the same instance.
>
yes but has you pointed out due to the bootstrapping the behaviour of the
SF will be strict JPA compliant.
>
> Another thing I was discussing with Andrea in chat is possibl
Hello,
We just released Hibernate Search 5.9.0.Beta1, with a new JSR 352
integration adding a mass indexing job with a resume-after-failure feature !
Check out our blog for more information about this release:
http://in.relation.to/2017/11/27/hibernate-search-5-9-0-Beta1/
Yoann Rodière
Hibernat
Sounds reasonable to me.
On 11/25/2017 12:45 PM, Steve Ebersole wrote:
> I just updated the text for the Jira[1].
>
> Specifically, in the section on SEQUENCE and TABLE, at the moment I have
> kept the legacy behavior of using "hibernate_sequence" as the name of the
> table/sequence - users must o
So then how about the following:
1. Add a multi-valued setting to define various categories of JPA
compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values
such as:
1. query (strict jpql compliance)
2. txn (transaction handling per spec)
3. close (multiple
That seems fine to me.
On 11/27/2017 04:29 PM, Steve Ebersole wrote:
> So then how about the following:
>
>
>1. Add a multi-valued setting to define various categories of JPA
>compliance. E.g. `hibernate.jpa.compliance` with multi-selectable values
>such as:
>1. query (strict jpql
I don't understand what is the requirement for the @Bag annotation and the
`hibernate.jpa.compliance=list` setting.
>From the JPA spec, only if we provide @OredrBy or @OrderColumn we get an
ordered List.
Otherwise, the order is undefined.
Is there anything I'm missing about handling Lists accordi
