+1, one less people will complain about :)
On Tue 2016-07-05 17:28, Steve Ebersole wrote:
> I'm ok with this. That is no longer a real requirement.
>
> Any disagree?
>
> On Tue, Jul 5, 2016, 11:58 AM Sanne Grinovero wrote:
>
> > Hi all,
> > today creating a unit test I was greeted by this "ol
This is something that has been bothering me for a long time. HHH-6328[1]
is a specific example. Basically we are very inconsistent in how we
attempt to match up table and column names, especially when there are
naming strategies involved. We see this with secondary tables,
@org.hibernate.annota
Tracked now as:
- https://hibernate.atlassian.net/browse/HHH-10935
Thank you all!
On 6 July 2016 at 17:49, Emmanuel Bernard wrote:
> +1, one less people will complain about :)
>
> On Tue 2016-07-05 17:28, Steve Ebersole wrote:
>> I'm ok with this. That is no longer a real requirement.
>>
>> An
Serializability of composite key types is mandated by the JPA spec, but I
suppose it's fine to be less strict in our implementation. Out of interest,
does anyone know why that requirement is part of the spec?
2016-07-06 22:19 GMT+02:00 Sanne Grinovero :
> Tracked now as:
> - https://hibernate.at
I believe the spec actually just says that the composite key class must be
serializable if the model is to be serialized (duh). I could be
misremembering, but I believe that is right.
The spec does not say anything about the serializability of simple keys
because the spec severely limits id types
Actually, I correct myself. The spec does say that composite keys must be
Serializable (section 2.4).
I'd say that we cover this under our "portability/compliance guidelines"
like we do for other JPA requirements that we "softly" require.
On Wed, Jul 6, 2016 at 5:23 PM Steve Ebersole wrote:
>
