[hibernate-dev] [feature request][discuss] smoother serializers integration?

2017-04-19 Thread Romain Manni-Bucau
Hi guys,

Short sumarry: Wonder if hibernate could get a feature to kind of either
unproxy or freeze the entities once leaving the managed context to avoid
uncontrolled lazy loading on one side and serialization issues on another
side.

Use case example: a common example is a REST service exposing directly
hibernate entities (which is more and more common with microservice
"movement").

Objective: the goal is to not need any step - or reduce them a lot -
between the hibernate interaction and a potential serialization to avoid
issues with lazy loading and unexpected loading. Today it requires some
custom and hibernate specific logic in the serializer which kind of breaks
the transversality of the two concerns (serialization and object
management/loading).


Implementation options I see:

1. a callback requesting if the lazy relationship should be fetched,
something like

public interface GraphVisitor {
boolean shouldLoad(Object rootEntity, Property property);
}

2. An utility to remove any proxy potentially throwing an exception and
replacing the value by null or an empty collection, something like

MyEntity e = Hibernate.deepUnproxy(entity);

3. A switch of the proxy implementation, this is close to 2 but wouldn't
require a call to any utility, just a configuration in the persistence unit.

Side note: of course all 3 options can be mixed to create a single solution
like having 3 implemented based on 1 for instance.

Configuration proposal: this would be activated through a property in the
persistence unit (this shouldn't be only global IMHO cause otherwise you
can't mix 2 kind of units, like one for JSF and one for JAX-RS to be
concrete). This should also be activable as a query hint i think - but more
a nice to have.


What this feature wouldn't be responsible for: cycles. If relationships are
bidirectional then the unproxied entity would still "loop" if you browse
the object graph - this responsability would stay in the consumer since it
doesn't depend on hibernate directly but more on a plain object handling.

What do you think?


Romain Manni-Bucau
@rmannibucau  |  Blog
 | Old Blog
 | Github  |
LinkedIn  | JavaEE Factory

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] 6.0 - concept naming

2017-04-19 Thread Christian Beikov
Sounds good. I hope the secondary table stuff is getting defined on a 
higher level(EntityPersister/AbstractEntityPersister). I had problems 
implementing OneToOne-JoinTable support for 
TablePerClass(UnionSubclassPersister) a while ago and I guess that was 
because there is no notion of secondary tables in the EntityPersister. I 
guess that issue would be solved then? :)


Mit freundlichen Grüßen,

*Christian Beikov*
Am 14.04.2017 um 18:24 schrieb Steve Ebersole:
>   Before I get deeper into this persister work I wanted to discuss some of
> the primary design concepts and start a discussion about naming the
> interfaces/classes related to them.
>
> I am thinking it would be best to model the tables associated with a
> persister using a similar structure we use for
> TableSpace/TableGroup/TableGroupJoin but in the non-specific-reference
> case.  For example, the Person entity might be mapped to 2 tables: the
> primary PERSON table, and a PERSON_SUPP secondary table.  Inside the
> persister we'd map the binding to those tables including the join criteria
> between them.  This is distinctly different from the structure of
> references to those tables as part of a specific query.  So inside
> persister we'd map a structure like:
>
> EntityPersister {
>  ...
>  rootTable = Table( PERSON )
>  secondaryTables = {
>  SecondaryTableBinding {
>  joinType = INNER
>  targetTable = Table( PERSON_SUPP )
>  predicate = {
>  EQ {
>  lhs = {
>  ColumnBinding( Column( Table( PERSON ), "id" )
>  }
>  rhs = {
>  ColumnBinding( Column( Table( PERSON_SUPP ), "p_id"
> )
>  }
>  }
>  }
>  }
> }
>
> We could simplify this if we follow the same assumption we do today that
> the secondary tables always use the root table as the lhs.  Additionally we
> might consider simplifying the join predicate to use the ForeignKey which
> already defines this join predicate info:
>
> EntityPersister {
>  ...
>  rootTable = Table( PERSON )
>  secondaryTables = {
>  SecondaryTableBinding {
>  joinType = INNER
>  targetTable = Table( PERSON_SUPP )
>  predicate = ForeignKey {
>  uid = 123456789ABC
>  ...
>  }
>  }
>  }
> }
>
>
> Compare this to the structure for a particular query[1], which is different:
>
> TableGroup
>  root = TableReference {
>  table = ( Table( PERSON ) )
>  identifiactionVariable = p0
>  tableJoins = {
>  TableReferenceJoin {
>  ...
>  }
>  }
>  }
> }
>
> Notice specifically the addition of the identifactionVariable (alias).
> Because we might have multiple references to that same table which need to
> be unique in the given query, e.g. a fetched or joined self-referential
> association (person -> manager).
>
> First, what do you think of these proposed structures?  And secondly what
> are y'alls opinions wrt the names?
>
> FWIW there are 2 main reasons I propose modeling things the way I suggest
> above in terms of the structure on persisters:
>
> 1. I think it makes it easier for consumers of persisters to understand
> the bindings
> 2. I *think* (tbd) that it makes it easier to "clone" into the query
> TableGroup structure.
>
> Anyway, would love feedback on this.
>
> [1]  Note that the class called `TableReference` here is called
> `TableBinding` in the currently pushed code, but I'd prefer to change that
> and instead have "binding" term reference the binding of the table in the
> persister model.  I am open to different naming here though.
> ___
> 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


Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

2017-04-19 Thread Christian Beikov
Hey Romain,

I don't think it is a good idea to expose entities directly if you 
really need a subset of the data.
Reasons for that thinking are that it gets hard to define what needs to 
be fetched or is safe to be used for a particular use case. Obviously 
serialization is like a follow-up problem.
I see 2 possible solutions to the problem and both boil down to the use 
of DTOs.

 1. Use an object mapper(e.g. Dozer) that maps entity object graphs to
custom DTO types.
 2. Use specialized DTOs in queries.


Implementing 1. does not help you with lazy loading issues and 2. might 
require very intrusive changes in queries which is why I implemented 
Blaze-Persistence Entity Views 
.
This is a library that allows you to define DTOs with mappings to the 
entity. In a query you can define that you want results to be 
"materialized" as instances of the DTO type.
This reduces the pain induced by properly separating the "presentation 
model" from the "persistence model" and at the same time will improve 
the performance by utilizing the mapping information.
I don't want to advertise too much, just wanted to say that I had the 
same issues over and over which is why I started that project.

Mit freundlichen Grüßen,

*Christian Beikov*
Am 19.04.2017 um 10:51 schrieb Romain Manni-Bucau:
> Hi guys,
>
> Short sumarry: Wonder if hibernate could get a feature to kind of either
> unproxy or freeze the entities once leaving the managed context to avoid
> uncontrolled lazy loading on one side and serialization issues on another
> side.
>
> Use case example: a common example is a REST service exposing directly
> hibernate entities (which is more and more common with microservice
> "movement").
>
> Objective: the goal is to not need any step - or reduce them a lot -
> between the hibernate interaction and a potential serialization to avoid
> issues with lazy loading and unexpected loading. Today it requires some
> custom and hibernate specific logic in the serializer which kind of breaks
> the transversality of the two concerns (serialization and object
> management/loading).
>
>
> Implementation options I see:
>
> 1. a callback requesting if the lazy relationship should be fetched,
> something like
>
> public interface GraphVisitor {
>  boolean shouldLoad(Object rootEntity, Property property);
> }
>
> 2. An utility to remove any proxy potentially throwing an exception and
> replacing the value by null or an empty collection, something like
>
> MyEntity e = Hibernate.deepUnproxy(entity);
>
> 3. A switch of the proxy implementation, this is close to 2 but wouldn't
> require a call to any utility, just a configuration in the persistence unit.
>
> Side note: of course all 3 options can be mixed to create a single solution
> like having 3 implemented based on 1 for instance.
>
> Configuration proposal: this would be activated through a property in the
> persistence unit (this shouldn't be only global IMHO cause otherwise you
> can't mix 2 kind of units, like one for JSF and one for JAX-RS to be
> concrete). This should also be activable as a query hint i think - but more
> a nice to have.
>
>
> What this feature wouldn't be responsible for: cycles. If relationships are
> bidirectional then the unproxied entity would still "loop" if you browse
> the object graph - this responsability would stay in the consumer since it
> doesn't depend on hibernate directly but more on a plain object handling.
>
> What do you think?
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github  |
> LinkedIn  | JavaEE Factory
> 
> ___
> 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


Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

2017-04-19 Thread Vlad Mihalcea
Hi,

Although I keep on seeing this request from time to time, I still think
it's more like a Code Smell.
Entities are useful for when you plan to modify them. Otherwise, a DTO
projection is much more efficient, and you don't suffer from
LazyInitializationException.

With the ResultTransformer, you can even build graphs of entities, as
explained in this article;

https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/

Due to how Hibernate Proxies are handled, without Bytecode Enhancement,
it's difficult to replace a Proxy with null after the Session is closed. If
we implemented this, we'd have to take into consideration both Javassist
and ByteBuddy as well as ByteCode Enhancements.

all in all, the implementation effort might not justify the benefit, and
I'm skeptical of offering a feature that does not encourage data access
Best Practices.

Vlad

On Wed, Apr 19, 2017 at 2:18 PM, Christian Beikov <
christian.bei...@gmail.com> wrote:

> Hey Romain,
>
> I don't think it is a good idea to expose entities directly if you
> really need a subset of the data.
> Reasons for that thinking are that it gets hard to define what needs to
> be fetched or is safe to be used for a particular use case. Obviously
> serialization is like a follow-up problem.
> I see 2 possible solutions to the problem and both boil down to the use
> of DTOs.
>
>  1. Use an object mapper(e.g. Dozer) that maps entity object graphs to
> custom DTO types.
>  2. Use specialized DTOs in queries.
>
>
> Implementing 1. does not help you with lazy loading issues and 2. might
> require very intrusive changes in queries which is why I implemented
> Blaze-Persistence Entity Views
> .
> This is a library that allows you to define DTOs with mappings to the
> entity. In a query you can define that you want results to be
> "materialized" as instances of the DTO type.
> This reduces the pain induced by properly separating the "presentation
> model" from the "persistence model" and at the same time will improve
> the performance by utilizing the mapping information.
> I don't want to advertise too much, just wanted to say that I had the
> same issues over and over which is why I started that project.
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 19.04.2017 um 10:51 schrieb Romain Manni-Bucau:
> > Hi guys,
> >
> > Short sumarry: Wonder if hibernate could get a feature to kind of either
> > unproxy or freeze the entities once leaving the managed context to avoid
> > uncontrolled lazy loading on one side and serialization issues on another
> > side.
> >
> > Use case example: a common example is a REST service exposing directly
> > hibernate entities (which is more and more common with microservice
> > "movement").
> >
> > Objective: the goal is to not need any step - or reduce them a lot -
> > between the hibernate interaction and a potential serialization to avoid
> > issues with lazy loading and unexpected loading. Today it requires some
> > custom and hibernate specific logic in the serializer which kind of
> breaks
> > the transversality of the two concerns (serialization and object
> > management/loading).
> >
> >
> > Implementation options I see:
> >
> > 1. a callback requesting if the lazy relationship should be fetched,
> > something like
> >
> > public interface GraphVisitor {
> >  boolean shouldLoad(Object rootEntity, Property property);
> > }
> >
> > 2. An utility to remove any proxy potentially throwing an exception and
> > replacing the value by null or an empty collection, something like
> >
> > MyEntity e = Hibernate.deepUnproxy(entity);
> >
> > 3. A switch of the proxy implementation, this is close to 2 but wouldn't
> > require a call to any utility, just a configuration in the persistence
> unit.
> >
> > Side note: of course all 3 options can be mixed to create a single
> solution
> > like having 3 implemented based on 1 for instance.
> >
> > Configuration proposal: this would be activated through a property in the
> > persistence unit (this shouldn't be only global IMHO cause otherwise you
> > can't mix 2 kind of units, like one for JSF and one for JAX-RS to be
> > concrete). This should also be activable as a query hint i think - but
> more
> > a nice to have.
> >
> >
> > What this feature wouldn't be responsible for: cycles. If relationships
> are
> > bidirectional then the unproxied entity would still "loop" if you browse
> > the object graph - this responsability would stay in the consumer since
> it
> > doesn't depend on hibernate directly but more on a plain object handling.
> >
> > What do you think?
> >
> >
> > Romain Manni-Bucau
> > @rmannibucau  |  Blog
> >  | Old Blog
> >  | Github  rmannibuc

[hibernate-dev] [feature request][discuss] smoother serializers integration?

2017-04-19 Thread Romain Manni-Bucau
Well here is how I see things:

1. mappers: until model is different from the jpa mapping it doesn't make
much sense and with microservices and failfast trends it doesn't make as
much sense as it was some years ago - plese don't assume I agree but just
sharing what I see.
1.bis. you get the same issue with mappers if you think about it but just
add a layer after hibernate to reject that responsability. Worse case you
give it to the end user which prevents can prevent libraries/tooling
2. Mapping is already a DTO and to not create 10 DTO models per domain
entity you will likely get the same issue there. You can move back the
responsability to the mapper but once again same issue.
3. The nice thing with this GraphVisitor proposal (name is likely very bad)
is you can just bypass not initialized instances, something like:

return (HibernateProxy.class.isInstance(value) &&
HibernateProxy.class.cast(value).getHibernateLazyInitializer().isUninitialized())
||
PersistentCollection.class.isInstance(value) &&
!PersistentCollection.class.cast(value).wasInitialized();


4. I also get a hard time to figure out why defaulting in case of a
detached entity is bad. Take the getSingleResult() example: spec throws an
exception if no result if found but most of usages are to wrap it to return
null instead cause it makes the code more fluent.

Also not sure how it can be different from data access best practise. Here
a usage i'm thinking about - the one I hit currently -:

// -start tx
Collection entities = em.createNamedQuery("query with
fetch")getResultList();
// here I loaded all the graph I need, what is still lazy doesnt need to be
loaded at all
// -end tx
// here the collection should just be as any DTO since it is no more in JPA
land

Now assume you use a DTO - which is the proposal, code will be:

Collection entities = fetchEntities();
Collection dtos = map(entities);
// here is MyDto has the representation of a relationship it will not lazy
load it but can still be called

What does it mean? There is still a gap in the JPA usage of entities with
hibernate and normal java code (openjpa for instance doesnt have that issue
since when the entity is detached it return what it has and doesnt try to
use any connection).

>From my point of view it affects the serializer case, of course, but also
the resource management (lazy connections are really really vicious and
rarely controlled). So at least a mode where the fetched value becomes kind
of no more aware of JPA would be great.


Hey Romain,
>
> I don't think it is a good idea to expose entities directly if you
> really need a subset of the data.
> Reasons for that thinking are that it gets hard to define what needs to
> be fetched or is safe to be used for a particular use case. Obviously
> serialization is like a follow-up problem.
> I see 2 possible solutions to the problem and both boil down to the use
> of DTOs.
>
>  1. Use an object mapper(e.g. Dozer) that maps entity object graphs to
> custom DTO types.
>  2. Use specialized DTOs in queries.
>
>
> Implementing 1. does not help you with lazy loading issues and 2. might
> require very intrusive changes in queries which is why I implemented
> Blaze-Persistence Entity Views
> .
> This is a library that allows you to define DTOs with mappings to the
> entity. In a query you can define that you want results to be
> "materialized" as instances of the DTO type.
> This reduces the pain induced by properly separating the "presentation
> model" from the "persistence model" and at the same time will improve
> the performance by utilizing the mapping information.
> I don't want to advertise too much, just wanted to say that I had the
> same issues over and over which is why I started that project.
>
> Mit freundlichen Gr??en,
> 
> *Christian Beikov*
> Am 19.04.2017 um 10:51 schrieb Romain Manni-Bucau:
> > Hi guys,
> >
> > Short sumarry: Wonder if hibernate could get a feature to kind of either
> > unproxy or freeze the entities once leaving the managed context to avoid
> > uncontrolled lazy loading on one side and serialization issues on another
> > side.
> >
> > Use case example: a common example is a REST service exposing directly
> > hibernate entities (which is more and more common with microservice
> > "movement").
> >
> > Objective: the goal is to not need any step - or reduce them a lot -
> > between the hibernate interaction and a potential serialization to avoid
> > issues with lazy loading and unexpected loading. Today it requires some
> > custom and hibernate specific logic in the serializer which kind of
> breaks
> > the transversality of the two concerns (serialization and object
> > management/loading).
> >
> >
> > Implementation options I see:
> >
> > 1. a callback requesting if the lazy relationship should be fetched,
> > something like
> >
> > public interface Graph

Re: [hibernate-dev] Negative sequence numbers

2017-04-19 Thread Steve Ebersole
See inline...

On Tue, Apr 18, 2017 at 8:36 PM Gail Badner  wrote:

> Should Hibernate support negative sequence values?
>

Absolutely.  Hibernate has historically supported decrementing and/or
negative values - so yes that should continue to work.


If so, is my proposed fix OK?
>

Define "OK" :)

As you said, your testing confirms that your proposed change "works".  So
from that simple perspective, yes it is "OK".  Although I think it can, and
maybe should, be slightly different - namely we really only need to encode
the increment value into the SEQUENCE definition when that increment is
something other than 1 (one) since that is the default increment for
SEQUENCEs.  So something like:

NoopOptimizer {
...
public boolean applyIncrementSizeToSourceValues() {
assert getIncrementSize() != 0;
return getIncrementSize() != 1;
}
}

Can increment for no-op be anything other than 1 or -1?  Zero is not valid.
 1 and -1 are both valid.  But what about 2 or -2?  I'm not sure that makes
sense.  The `!= 1` check handles that case.

However, I do have a concern about the design here and moving forward.  I
think there is some amount of technical debt here, and I think there was a
lot of confusion present even in the original code I wrote here.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] 6.0 - concept naming

2017-04-19 Thread Steve Ebersole
On Wed, Apr 19, 2017 at 6:00 AM Christian Beikov 
wrote:

> Sounds good. I hope the secondary table stuff is getting defined on a
> higher level(EntityPersister/AbstractEntityPersister). I had problems
> implementing OneToOne-JoinTable support for
> TablePerClass(UnionSubclassPersister) a while ago and I guess that was
> because there is no notion of secondary tables in the EntityPersister. I
> guess that issue would be solved then? :)
>

Not sure what you mean by "higher level".  The design here specifically
shows secondary tables modeled as top-level concepts (SecondaryTableBinding).
So I think, again iiuc, that the design already shows secondary tables
"defined on a higher level".
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev


Re: [hibernate-dev] [feature request][discuss] smoother serializers integration?

2017-04-19 Thread Steve Ebersole
This was actually the intent of the original introduction of EntityMode and
specifically the DOM4J EntityMode.  But that stuff was deemed "outside the
scope" of Hibernate proper.

As  others have stated in reply, I think this is really best served by a
use-case-specific combination of dynamic fetching and serializers+
deserializers.  Example of serializers+ deserializers include:

   1. converting to/from DTO/SDO objects
   2. converting to/from XML representations (JAXB, marshallers, etc)
   3. etc

I'll second Vlad's conclusion that "the implementation effort might not
justify the benefit" and actually even take it a step further... I think
implementing this in Hibernate is not TheRightWay(tm) to do this
functionality.

On Wed, Apr 19, 2017 at 6:33 AM Vlad Mihalcea 
wrote:

> Hi,
>
> Although I keep on seeing this request from time to time, I still think
> it's more like a Code Smell.
> Entities are useful for when you plan to modify them. Otherwise, a DTO
> projection is much more efficient, and you don't suffer from
> LazyInitializationException.
>
> With the ResultTransformer, you can even build graphs of entities, as
> explained in this article;
>
>
> https://vladmihalcea.com/2017/04/03/why-you-should-use-the-hibernate-resulttransformer-to-customize-result-set-mappings/
>
> Due to how Hibernate Proxies are handled, without Bytecode Enhancement,
> it's difficult to replace a Proxy with null after the Session is closed. If
> we implemented this, we'd have to take into consideration both Javassist
> and ByteBuddy as well as ByteCode Enhancements.
>
> all in all, the implementation effort might not justify the benefit, and
> I'm skeptical of offering a feature that does not encourage data access
> Best Practices.
>
> Vlad
>
> On Wed, Apr 19, 2017 at 2:18 PM, Christian Beikov <
> christian.bei...@gmail.com> wrote:
>
> > Hey Romain,
> >
> > I don't think it is a good idea to expose entities directly if you
> > really need a subset of the data.
> > Reasons for that thinking are that it gets hard to define what needs to
> > be fetched or is safe to be used for a particular use case. Obviously
> > serialization is like a follow-up problem.
> > I see 2 possible solutions to the problem and both boil down to the use
> > of DTOs.
> >
> >  1. Use an object mapper(e.g. Dozer) that maps entity object graphs to
> > custom DTO types.
> >  2. Use specialized DTOs in queries.
> >
> >
> > Implementing 1. does not help you with lazy loading issues and 2. might
> > require very intrusive changes in queries which is why I implemented
> > Blaze-Persistence Entity Views
> > .
> > This is a library that allows you to define DTOs with mappings to the
> > entity. In a query you can define that you want results to be
> > "materialized" as instances of the DTO type.
> > This reduces the pain induced by properly separating the "presentation
> > model" from the "persistence model" and at the same time will improve
> > the performance by utilizing the mapping information.
> > I don't want to advertise too much, just wanted to say that I had the
> > same issues over and over which is why I started that project.
> >
> > Mit freundlichen Grüßen,
> > 
> > *Christian Beikov*
> > Am 19.04.2017 um 10:51 schrieb Romain Manni-Bucau:
> > > Hi guys,
> > >
> > > Short sumarry: Wonder if hibernate could get a feature to kind of
> either
> > > unproxy or freeze the entities once leaving the managed context to
> avoid
> > > uncontrolled lazy loading on one side and serialization issues on
> another
> > > side.
> > >
> > > Use case example: a common example is a REST service exposing directly
> > > hibernate entities (which is more and more common with microservice
> > > "movement").
> > >
> > > Objective: the goal is to not need any step - or reduce them a lot -
> > > between the hibernate interaction and a potential serialization to
> avoid
> > > issues with lazy loading and unexpected loading. Today it requires some
> > > custom and hibernate specific logic in the serializer which kind of
> > breaks
> > > the transversality of the two concerns (serialization and object
> > > management/loading).
> > >
> > >
> > > Implementation options I see:
> > >
> > > 1. a callback requesting if the lazy relationship should be fetched,
> > > something like
> > >
> > > public interface GraphVisitor {
> > >  boolean shouldLoad(Object rootEntity, Property property);
> > > }
> > >
> > > 2. An utility to remove any proxy potentially throwing an exception and
> > > replacing the value by null or an empty collection, something like
> > >
> > > MyEntity e = Hibernate.deepUnproxy(entity);
> > >
> > > 3. A switch of the proxy implementation, this is close to 2 but
> wouldn't
> > > require a call to any utility, just a configuration in the persistence
> > unit.
> > >
> > > Side note: of course all 3 options can be mixed to create