Wrt to bag versus list, it's more the inability to fetch multiple bags,
which is perfectly legal in JPA but is an exception in Hibernate.
If have to search for the exact section, but afair to JPA a List defined as
OneToMany or ManyToMany has an implicit OrderColumn if one is not
provided. And in
Makes sense. I think it's reasonable to add this since this is what a
many-to-many table relationship looks like.
But, it's ok to postpone it until 6.0.
Vlad
On Tue, Nov 28, 2017 at 12:38 PM, andrea boriero
wrote:
> It is not about the order but about duplicates.
>
> With the following
> class
It seems fine to me and I agree to delay the @Bag to 6.0.
On 27 November 2017 at 21:29, 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 valu
It is not about the order but about duplicates.
With the following
class A {
List bsl
@JoinTable(name = "A_B",
joinColumns = @JoinColumn(name = "A_ID"),
inverseJoinColumns = @JoinColumn(name = "B_ID"),
)
@ManyToMany
public List getBs() {
return b;
}
}
class *B*{
List as;
..
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
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
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
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
> 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
Andrea, SF is a EMF. Unwrapping simply returns the same instance.
Another thing I was discussing with Andrea in chat is possibly making these
multi-valued, or having multiple values for this. I can't imagine the FQN
case is really all that appealing to a user. I'm fairly certain a user
would ra
I should have said:
Another thing I was discussing with Andrea in chat is possibly making these
multi-valued, or having multiple values for this. I can't imagine the FQN
case is really all that appealing to a user. I'm fairly certain a user
would rather simply say "yeah, treat transactions accor
I think for 5.3 it's still fine to rely on isJpaBootstrap may be
documenting that a SF obtained from unwrapping an EMF will conform to the
JPA spec in term of exceptions.
On 16 November 2017 at 21:09, Vlad Mihalcea wrote:
> When I said multiple modes, I was thinking of defining all these situat
When I said multiple modes, I was thinking of defining all these situations
In some interface which declares methods like:
boolean throwsExceptionWhenClosingAClosedEMF()
The interface can have two implementations for Strict JPA and Native mode.
However, the setting could take the FQN of the inte
There is already a similar setting, although specific to query language:
`hibernate.query.jpaql_strict_compliance` - so there is precedence for such
a solution.
I'm not sure about the "with multiple modes" aspect though. What are these
other enumerated mode values?
On Thu, Nov 16, 2017 at 2:15
Where the JPA way is questionable, let's add one configuration:
hibernate.jpa.compliance with multiple modes:
- strict: we do whatever the JPA standard says we should do, like throwing
an exception when trying to close the EMF twice
- native: we bend the rule where we don't agree with the standard
It was added deprecated. Meaning I added it knowing it would go away and I
wanted to avoid users using it.
BTW, I am talking about a 5.3 release specifically covering 5.2 + JPA 2.2.
Yes there is a longer term aspect as well with 6.0 and beyond.
Its specifically the "where the JPA way is question
Hi Steve,
I think that for 5.2 was ok to have the isJpaBootstrap method to avoid
breaking compatibility for the native bootstrap.
For 6.0, maybe it's easier if we just align to the JPA spec where it makes
sense,
and only provide a separation where the JPA way is questionable.
I noticed that the i
17 matches
Mail list logo
