Re: [hibernate-dev] Question..
by Steve Ebersole
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.
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. 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.
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). 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.
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.
On Fri, Sep 1, 2017 at 4:14 PM Gail Badner <gbadner(a)redhat.com> wrote:
> Hi Steve,
>
> No, I didn't hear back from you.
>
> I asked for a response to an email sent to hibernate-dev mailing list with
> subject, "HHH-11898: more "empty" composite issues".
>
> You can ignore the first message and just read the 2nd one.
>
> Thanks,
> Gail
>
> On Fri, Sep 1, 2017 at 12:53 PM, Steve Ebersole <steve(a)hibernate.org>
> wrote:
>
>> You asked me to comment on an email, I'm sorry but I don't remember if I
>> did. Did I respond to you?
>
>
>
9 years
Hibernate Validator 6.0.3.Final released
by Guillaume Smet
Hi,
We just released Hibernate Validator 6.0.3.Final. It fixes a few
issues reported by our users, adds a new SPI for providing a custom
ScriptEvaluatorFactory, introduces a new @CodePointLength constraint
and is faster than ever.
It is a recommended upgrade for everyone already using 6.0.x.
For more information, read the announcement here:
http://in.relation.to/2017/10/19/hibernate-validator-603-final-out/ .
We also released maintenance releases for the 5.3 and 5.4 branches but
we recommend that all users should upgrade to 6.0 now.
Have a nice day!
--
Guillaume
9 years
<join ... fetch="select"/>
by Steve Ebersole
Hibernate mappings define a feature to allow a secondary table (`<join/>`
in hbm terms) to be defined as not joined via : `<join ...
fetch="select"/>`. 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.
9 years
Statements leaks when using JPA StoredProcedureQuery API
by Robert Marcano
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...
9 years
Re: [hibernate-dev] Statements leaks when using JPA StoredProcedureQuery API
by Robert Marcano
On 10/11/2017 03:15 PM, Vlad Mihalcea wrote:
> You can open a GitHub issue for JPA. Meanwhile, you can work around it
> as you suggested.
Opened an issue on JPA spec https://github.com/javaee/jpa-spec/issues/162
>
> On 11 Oct 2017 9:08 pm, "Robert Marcano" <robert(a)marcanoonline.com
> <mailto:robert@marcanoonline.com>> 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
> <http://www-01.ibm.com/support/docview.wss?uid=swg21504334>
> [2]
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
> <https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...>
>
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
9 years
@db.dialect@ - yet again
by Steve Ebersole
I just upgraded to IntelliJ 2017.3 EAP and am back to this frustrating
"Dialect class not found: @db.dialect@" problem. I run the
`processTestResources` (or `compile`, does not matter) and then when I try
to run a test in the IDE I get this error.
What is the magic incantation I am missing?
9 years
Property "ogm.datastore.create_database": fit for purpose?
by Sanne Grinovero
This property is defined in hibernate-ogm-core and while it's quite
self-explanatory with other NoSQL stores, it doesn't translate nicely
to the Infinispan scenario.
I'd be tempted to introduce ad-hoc properties for each Dialect so that
their effect is clear, allowing to pick more fitting names.
We also like to keep configuration properties to the minimun. In fact
I'd like to simply use Environment.HBM2DDL_AUTO to create / define
Caches ?
Conceptually in Infinispan they are closer to "tables" than
"databases", except they are all schema less and we deploy a schema
using a different operation..
Let the fight begin!
Thanks,
Sanne
9 years
