I more just mean from a documentation perspective. I don't plan on
removing the feature itself so much. Although I guess we can revisit that
when we rework annotation binding and finish up model binding in general
On Tue, Aug 4, 2015, 1:51 AM Gunnar Morling wrote:
> FWIW, that's one of the map
FWIW, that's one of the mapping patterns I always found awkward, so +1 for
deprecating it from me.
What would be the strategy, though? Deprecate in 5 and remove in 6?
2015-08-03 17:46 GMT+02:00 Sanne Grinovero :
> I remember loving this feature.
> Composite keys are very common in databases I wo
I remember loving this feature.
Composite keys are very common in databases I worked with, while
loading by ids seems to be quite uncommon in my coding style as I
don't remember knowing how to do that, nor that this ignorance ever
bothered me :)
+1 anyway, that's just to give some perspective.
On
Here is what I proposes in the documentation in the section discussing
composite identifiers:
Technically a composite identifier can be made up of just a
single persistent attribute.
The restriction that a composite identifier has to be
represented by a "primary ke
I am thinking we should start to soft-deprecate[1] the historical feature
of embedded composite identifiers. This is the feature that allowed an
entity to define a composite identifier without any kind of "pk class"
(EmbeddedId/IdClass):
@Entity
public class MyEntity {
@Id
public Integer
