Nope
On Thu, Sep 1, 2016, 4:25 PM Sanne Grinovero wrote:
> Hi all,
> the Infinispan/Hibernate integration test - which is run by the
> Infinispan team and uses TeamCity instead of Jenkins - is failing with
> the below cryptic error.
>
> Did the ORM switch to using Git modules?
>
> Error collecti
Hi all,
the Infinispan/Hibernate integration test - which is run by the
Infinispan team and uses TeamCity instead of Jenkins - is failing with
the below cryptic error.
Did the ORM switch to using Git modules?
Error collecting changes for VCS repository
'"https://github.com/hibernate/hibernate-orm
Hi Christian,
I've been following your discussion on HHH-11042 and thinking about your
solution. I am concerned that some dialects do not treat null the way you
describe. SQL Server has a property that changes how null is treated:
SET ANSI_NULLS { ON | OFF } [1]
[1] mentions that in a future rel
Tarek -
See inline.
On 09/01/2016 10:11 AM, Dev Stack wrote:
> Hi Chris,
>
> Thank you for your answer.
>
> 1) yes, we can use Set<>
> 2) When we load an offer we have to load also the associated product.
> So, we have to keep the link from offer to product.
> the link from product to offer is no
Hi Chris,
Thank you for your answer.
1) yes, we can use Set<>
2) When we load an offer we have to load also the associated product.
So, we have to keep the link from offer to product.
the link from product to offer is not needed for now.
Thanks,
Tarek
2016-09-01 15:55 GMT+02:00 Chris Cranford :
Tarek -
There are a few ways we can tackle what you want all within the scope of
Envers,
but some of it highly depends upon details specific to the relationship
between
Product (P) and Offer (O).
1. What is the collection type used in Product for the related offers?
If this happens to be a
Am 01.09.2016 1:13 nachm. schrieb "Steve Ebersole" :
>
> Hit send accidentally...
>
> The "problem" is normalization. You are storing a TZ that is specific to
the place (Austin, London) a shipment event occurs on the shipment event.
So even if your app had the requirment to display the shipment e
In order to validate that unifying the event listener impls between
"native" and "jpa" is actually workable I applied that idea on top of 5.2.
And it works. ANd since I did the work, I created a PR from it for us to:
1. review that specific set of changes (slightly different accounting
for
Hit send accidentally...
The "problem" is normalization. You are storing a TZ that is specific to
the place (Austin, London) a shipment event occurs on the shipment event.
So even if your app had the requirment to display the shipment event in the
local TZ that that event occurred in, data-norma
I think your example is actually a perfect example of when to not store the
TZ.
On Thu, Sep 1, 2016, 5:16 AM Gunnar Morling wrote:
> > Saving in "timezoned" instants is prone to several bugs: you're then
> > exposed to ambiguities as time doesn't flow linearly in all zones.
>
> I see it the othe
Hey,
I wanted to start a discussion regarding this issue:
https://hibernate.atlassian.net/browse/HHH-11042
Although the Dialect class contains the method
"supportsTupleDistinctCount", it is never used, so when doing a count
distinct on a tuple, it just renders the tuple instead of doing a
fal
Hello,
we have in our model entity P (product) and entity O (offer). The two
entities have a link.
one instance of P can have one or many O instances.
an instance O has a reference to only one instance of P.
The link is managed in the O side.
P and O are revisioned by Hibernate Envers.
Two use c
> Saving in "timezoned" instants is prone to several bugs: you're then
> exposed to ambiguities as time doesn't flow linearly in all zones.
I see it the other way around: the indirection you suggest is prone to
errors.
Rules about TZ constantly change (e.g. when switching to/from DST),
locations
To be fair I would have mapped that differently.
Your Shipment arrives at a certain *point in time* (long, UTC based)
in a certain Port (mapped with Foreign Key).
A Port would have a reference to a local Timezone, and UI could decide
to use that (or a different one) for rendering, based on other
as
Regarding
> LocalDateTime [...]
> When binding we would resolve this into the JVM/JDBC TZ (using
> LocalDateTime#atZone(jvmJdbcZoneId)
Couldn't you rather use UTC when handling these TZ-less types?
This will make the solution more robust in cases where you requirement "JVM
TZ when saving = JVM T
Hi,
For the moment, by adding a SF/Session-level configuration, we can at least
save Timestamps in UTC, which is indeed a very common scenario.
Later on, we can address the situation that you described in this email by
adding new types or introducing a new annotation to specify the secondary
fiel
16 matches
Mail list logo
