2014-03-11 17:45 GMT+01:00 Sanne Grinovero <sa...@hibernate.org>:
> On 11 March 2014 10:59, Gunnar Morling <gun...@hibernate.org> wrote:
> > 2014-03-09 18:31 GMT+01:00 Steve Ebersole <st...@hibernate.org>:
> >
> > @Entity
> >> interface Employee {
> >> ...
> >> }
> >>
> >> 2) We'd dynamically generate a class to back this. This generated class
> >> can contain many of the performance tweaks we've been developing via
> >> bytecode extensions (inline dirty-checking, "entity entry" info, etc).
> >>
> >
> > In which situation would one make use of this? This seems to encourage
> > "anemic data models", i.e. entities which are just data holders but don't
> > contain any business logic. Often it's very useful though to add logic
> > dealing with an entity's state to the entity type itself.
>
> I actually see this going in the opposite direction. Allowing to move
> all the mapping stuff to a different interface would encourage me to
> think of the implementation as something which can include code, and I
> could even have multiple types having different *implementations* if
> the non-persistent methods.
>
> It would also fight usage of inheritance, which is common among JPA
> users and something that I'd gladly avoid.
>
> Would be a very nice to have to avoid anemic data models.
>
I'm not following. The idea in 2) (which I was referring to) was to
*generate* the implementation class. How does a custom implementation play
into this? Are you referring to alternative 1) maybe?
>
> >
> > Will the class be generated at build or runtime? In case of the latter,
> how
> > would one instantiate such entity?
> >
> > On a somewhat related note, I've been contemplating the notion of
> > "partially mapped entities" in OGM [1]. Those would provide explicit
> > properties only for some attributes (common ones, or ones which business
> > logic relates to), while others would be exposed via a generic map
> > structure:
> >
> > @Entity
> > public class Product {
> >
> > @Id
> > private long id;
> > private String name;
> > private BigDecimal price;
> >
> > @AdditionalProperties
> > private Map<String, Object> additionalProperties;
> >
> > // ...
> > }
> >
> > This would be very beneficial for NoSQL use cases where you want to pass
> > through data from the store to a GUI in a generic manner or during
> > prototyping/rapid development, where you manifest more and more
> attributes
> > as explicit properties, just as business logic requires it.
> >
> > --Gunnar
> >
> > [1] https://hibernate.atlassian.net/browse/OGM-470
> >
> > _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
