Re: [hibernate-dev] Question..

[Gail Badner]

Hi Steve,

I'm circling back to this. Please see below...

On Sat, Sep 2, 2017 at 8:47 AM, Steve Ebersole  wrote:
> I don't have the original email to reply to.  So I'll reply here.
>
> Overall, I had not really considered the primitive attribute case, but yeah
> that's clearly an issue.  My mistake.
>
> A) I agree that the con here is huge.  Not the best option
>
> B) Is close to better.  We could certainly check this and throw an error.

Throwing an exception is option A.

>  A better logical option is to do similar to what we do for ids and 
> versions...
> on startup instantiate one of these and grab/store its initial state when
> freshly instantiated.  We can later use those values to perform the empty
> check.  This is more logical, but not sure how "practical" it is given that
> we do not really have a good place to keep this relative to an embeddable,
> nor relative to an embedded, aside from CompositeType, but that does not
> feel right.

Is this what you refer to as (B) (expanded)?

My first email in the thread (which I told you to disregard) basically
suggests doing this. I told you to disregard it because I realized
that it would have serious issues.

Please see an example of the consequences when the embedded represents
an ID: 
https://github.com/hibernate/hibernate-orm/pull/1993/commits/329354bfa4bd86190252f1d5a7019f8b06c21b17

> This is better in 6 as we have an actual runtime model
> representation of the embedded and embeddable - but of course that does not
> help us in 5
>
> C) I really hate exposing `ComponentType` on a new SPI interface considering
> the type system is completely revamped in 6.  This would be (1) a very short
> lived contract in this form and therefore (2) means yet another pain point
> for user upgrading 5->6.  Ultimately I think this is the most promising
> solution moving forward (possibly coupled with the "expanded" B option)..
> However, that said, I am not sure we have a choice prior to 6 if we want to
> go this route - we'd have to expose the CompositeType..  There is no good
> singular thing prior to 6 to describe a embedded/embeddable.  To clarify
> what sounds like a misunderstanding though, CompositeType is unique to each
> embedded usage, not embeddable.  The CompositeType however does not expose
> its "role", so not sure if that distinction helps here.

Thanks for mentioning this. I'd forgotten that CompositeType is for
the "embedded" (JPA meaning)  type.

If it's possible to get the role set in ComponentMetamodel, then it
seems we could use the role instead of the ComponentType in
EmptyCompositeStrategy SPI. H5 could determine the Type using the
role. Would that work in H6 as well?

(I noticed I had a redundant argument (Object component) in
EmptyCompositeStrategy#isEmptyComposite; it's removed below)

public interface EmptyCompositeStrategy {
/**
 * Should a composite/embeddable be instantiated when a null attribute
 * having the specified role is read?
 *
 * @return true if Hibernate should instantiate a composite/embeddable
 * object when a null composite attribute is read.
 */
boolean supportsEmptyComposite(String role);

/**
 * Is the specified value an empty composite that should be considered
 * equal to null?
 *
 * @return true if the specified value is an empty composite.
 */
boolean isEmptyComposite(String role, Object value,
SessionFactoryImplementor factory);
}

>
> To make sure I understand your (D)... you mean to allow users to disable
> this option globally but to allow this option per specific embedded?  Longer
> term (6) I think this is something else we ought to support as well as the
> inverse (globally opt-in, but allowing a local opt-out).

This is what I was suggesting, although I see I had a typo. It should have said:

D) Provide a way to opt-in when
hibernate.create_empty_composites_strategy=false, or to opt-out when
hibernate.create_empty_composites_strategy=true.

> That's not necessarily a strategy though for dealing with embeddeds that are 
> "opted-in"
> that happen to use primitives.  Yes, it allows the user to more actively and
> selectively manage that themselves, but if they happen to opt-in an embedded
> which contains primitives we have the same issue to deal with.

I'm not sure I'm following this.

In the case where an application opts-in using
hibernate.create_empty_composites_strategy=true, and there is an
embeddabIe with primitive or non-null initialized values, I think it
would be reasonable to throw an exception as described by (A).

>
> Longer term I see allowing a mix of (B) (expanded), (C) and (D).
>
> For the short term (5), I think a the (possibly expanded) (B) option is the
> best.  I say that because (a) I prefer to not add a new contract like this
> for a bug-fix release and (b) the concern about the immediate contract
> change in 6.  If we all deem that this is acceptable, I's be fine with (C)
> as well.
>

If I'm 

[hibernate-dev] Programmatic entity mapping API

[Gunnar Morling]

Hi all,

This has crossed my mind for a few times: should we provide a programmatic
API in Hibernate ORM for mapping entities, as an alternative mapping
definition source to annotations and XML? I.e. something similar to the
programmatic mapping APIs we have in Hibernate Validator and Search.

It'd probably be a fair bit of work (though giving lots of fun with API
design), but I can see how it could be appealing to folks preferring
API-style ways of configuring their stack, which seems more and more en
vogue these days. Using lambda expressions would be attractive especially
when it comes to plugging in custom behaviours, e.g. for value generators.

Any thoughts?

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

Re: [hibernate-dev] Statements leaks when using JPA StoredProcedureQuery API

[Steve Ebersole]

The conceptualization of a Query for both Hibernate and JPA is that you
execute it and get back the result of that execution: a List, a single
result, a ScrollableResult, a Stream, etc.

Yet then JPA throws in StoredProcedureQuery which is completely different
conceptually.  Here you execute and then (statefully!!!) access the
individual pieces of that execution's results.

Sadly the JPA StoredProcedureQuery API is just messed up.  In my opinion
(yes, of course I'm biased) our ProcedureCall + ProcedureOutputs model is
MUCH better. It is more in line with that conceptualization of Query ->
Result as opposed to StoredProcedureQuery's Query -> Query-as-Result.

All that said...

What you are asking for here is to implicitly close the JDBC
CallableStatement when we recognize  that signifies
the exhaustion
of the execution results.  What is that condition?  Can't be just when
there are no more ResultSets in the CallableStatement's pipeline.  Consider
calling StoredProcedureQuery#getOutputParameterValue (which would require
accessing the CallableStatement) *after* we have implicitly closed the
CallableStatement.

So what is that condition?  That's the rub...


On Wed, Oct 11, 2017 at 1:07 PM Robert Marcano 
wrote:

> Migrating code from the Hibernate API to JPA, I found a stored procedure
> being called on a loop that was generating DB2 errors [1] on tests. This
> error is caused in this case for having a lot of not closed statements.
>
> The problem didn't happen using ProcedureCall Hibernate API because the
> method getOutputs() and release() from the Outputs instance are available.
>
> StoredProcedureQuery JPA API doesn't have any way to "close" the query
> and by that, the statement. Reusing the same instance of
> StoredProcedureQuery trying to only leak an unclosed statement but that
> doesn't help either, ProcedureCallImpl is creating a new statement for
> every call [2].
>
> The only option is to unwrap the StoredProcedureQuery to an
> StoredProcedureQuery and release the Outputs instance.
>
> I don't think there is a way to avoid this without enhancing the JPA
> API. Client code can call an store procedure and in some cases not
> caring about all the results, so there is no way for a JPA
> implementation to know when to close the statement.
>
> Making StoredProcedureQuery an AutoCloseable may help, but it will
> contrast with other Query types that don't need to be closed.
>
> Note: It is not frequent to call many store procedures on a loop, I
> would have preferred to just create a new procedure with the loop, but
> for this application the conditions about when to call the procedure for
> each iteration are outside the database.
>
> [1] http://www-01.ibm.com/support/docview.wss?uid=swg21504334
> [2]
>
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/procedure/internal/ProcedureCallImpl.java#L437
>
>
> ___
> 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]

[Steve Ebersole]

Hibernate mappings define a feature to allow a secondary table (``
in hbm terms) to be defined as not joined via : ``.  This actually creates a subsequent select to load the
data from the secondary table.

I am trying to figure out how to best incorporate this into the paradigm
for JDBC statement execution in 6.0.  My first thought was "do we need to
keep this?".  Does anyone know of a real usage of this feature?  In theory
it could be useful to some degree along with bytecode enhanced interception
for lazy-loading individual attributes.  But even then, I'm not sure how
practically useful that is.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev