HHH-10162 Inheritance and L2 cache
by Christian Beikov
Hey guys,
Steve said I should start a discussion about the possible solution for
HHH-10162 <https://hibernate.atlassian.net/browse/HHH-10162> so here we go.
While debugging the issue, I found out that the proxy is created at
DefaultLoadEventListener.createProxyIfNecessary() where it IMO should
consult the 2L cache first by calling existing =
loadFromSecondLevelCache( event, persister, keyToLoad );. The fix looks
easy, but I am not sure of the implications. Obviously this will affect
performance a little since it has to consult the L2 cache now.
I tried to start a discussion in the Dev room, but so far only Andrea,
Vlad and Chris have commented this. Has anyone a different idea for
implementing this?
--
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
6 years, 11 months
CDI / ORM / WildFly / Search integration plumbing
by Sanne Grinovero
Hi all,
In Hibernate Search we have a snippet of code doing:
private static BeanManager getBeanManager(Map<?, ?> configurationValues) {
return (BeanManager) configurationValues.get(
AvailableSettings.CDI_BEAN_MANAGER );
}
This used to work on WildFly 10 - even if we were to override the
Hibernate ORM version to 5.2.
By runnning the same integration test on WildFly 11 I'm now getting a
ClassCastException as the returned instance is of type
`org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does
implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but
does not implement the standard
`javax.enterprise.inject.spi.BeanManager` interface.
I'm unsure if this is a bug in the Search code or a misunderstanding
between the WildFly / ORM integration?
This javadoc seems relevant:
/**
* Used to pass along the CDI BeanManager, if any, to be used.
*/
String CDI_BEAN_MANAGER = "javax.persistence.bean.manager";
or should I interpret this property as meant only for "write" purposes
into the ORM configuration? I suppose it's unexpected that we attempt
to retrieve this as well.
Thanks,
Sanne
7 years, 2 months
ETA Hibernate-ORM 5.2.11 release?
by Karel Maesen
Hi,
I've got a user who is waiting for some months on a fix that is scheduled
for the 5.2.11 release(HHH-11283
<https://hibernate.atlassian.net/browse/HHH-11283>). He's getting a bit
impatient. Is there something I can tell him about an expected release date
for 5.2.11?
FYI: the issue is not a real blocker, and a simple workaround has been
proposed to the user in question.
Regards,
Karel
7 years, 2 months
Deprecated methods of NativeQuery via SQLQuery
by Guillaume Smet
Hi,
In OGM tests, we have a lot of warnings on this sort of constructs:
NativeQuery query = session.createNativeQuery( nativeQuery ).addEntity(
OscarWildePoem.class );
because addEntity() comes from SQLQuery and SQLQuery is deprecated.
I don't think it's a good thing for our users as they have a warning and
they can't really do anything about it.
I have a vague rememberance of a discussion about it a few months ago but
I don't remember the outcome of it.
Shouldn't we copy all the non deprecated methods of SQLQuery to NativeQuery
so that our users don't get a warning?
Or maybe I missed something?
Thanks!
--
Guillaume
7 years, 2 months
Hibernate ORM modules for Wildfly 11
by Sanne Grinovero
Hi all,
WildFly 11 is coming: the version 11.0.0.CR1 was just released last week.
The jipijapa integration point is slightly different.
It shouldn't be hard to patch the current ORM build for this, but I'm
wondering if we just want to update the target WF version, or start
producing sets for both WildFly 10 and WildFly 11 ?
Personally as soon as we can move all integration tests to WildFly 11,
I won't be interested in maintaining WF10 compatibility for the 5.2
branch of Hibernate ORM (and related projects) so I'd be inclined to
simply update the WF version.
The motivations:
- people are asking already for ORM modulesets for WF11
- these modules missing are a blocker for producing modulests for out
other projects, e.g. Hibernate Search
- people are asking for latest Hibernate Search modulesets for WF11 as well..
I'd treat this with urgency: while I don't expect any compatibility
issue with WF11 it would be nice to be able to test it all before it's
released as .Final
Thanks,
Sanne
7 years, 2 months
NoORM IRC meeting minutes
by Guillaume Smet
Hi,
No bot today so here are the minutes, carefully copy/pasted manually.
Have a nice day, all!
15:06 < gsmet> so Emmanuel, I suppose you don't have any news on the
Hibernate front?
15:06 < gsmet> #topic Progress Emmanuel
15:06 < emmanuel> No
15:06 < emmanuel> Though I asked on another mailing list the benefit of
15:07 < emmanuel> StackOverflow and removing the forum (or making read only)
15:07 < emmanuel> Spring went that way
15:07 < emmanuel> But that's not a high priority thread
15:07 < gsmet> OK
15:07 < gsmet> #topic Next 2 weeks Emmanuel
15:07 < gsmet> anything planned for the next 2 weeks?
15:09 < emmanuel> If anything, I think I will want to start looking at the
cloud friendly ORM version
15:09 < emmanuel> around connection etc
15:09 < emmanuel> something I had started a few months ago
15:09 < emmanuel> but no guarantee
15:09 < gsmet> OK, nice
15:10 < sannegrinovero> speaking of that, I had some input from a potential
contributor about using ORM in OS
15:10 < sannegrinovero> he promised he'll either blog about it or comment
on your related blog post
15:10 < emmanuel> sweet
15:10 < emmanuel> do you keep track of promises?
15:10 < emmanuel> :)
15:10 < sannegrinovero> yes
15:11 < sannegrinovero> and he has good motivation as he's one of our
candidates ;)
15:11 < alesj> sannegrinovero: still waiting on your email about JDK9 … for
JavaSI … ;-)
15:12 < gsmet> emmanuel: anything to add?
15:12 < sannegrinovero> alesj, sorry I'm back since this morning :) pile of
emails to process today!
15:12 < emmanuel> nope
15:12 < gsmet> #topic Progress Guillaume
15:12 < gsmet> We released a 6.0.2.Final of HV due to a nasty bug
15:13 < gsmet> they already updated GlassFish with this version
15:13 < gsmet> so the first 5 version of GF should contain this version
15:14 < gsmet> on the HV front, I'm mostly reviewing PR and spending a few
half days on it per week
15:14 < gsmet> I started to work more on OGM
15:14 < gsmet> upgraded all the components
15:15 < gsmet> I had a hard time upgrading Neo4j as they changed quite a
lot of things
15:15 < gsmet> also OGM now targets JDK 8
15:15 < gsmet> I also worked on the ORM 5.2 support
15:15 < gsmet> it's a long journey
15:15 < gsmet> I have something working except one JTA issue in Neo4j tests
15:16 < gsmet> I'll ask Davide if he has some idea when he's back
15:16 < gsmet> I pushed a few PRs to ORM
15:16 < gsmet> I have another one in the queue
15:16 < gsmet> and I'm working on trying to reduce significantly the amount
of copied code in OgmSessionImpl
15:17 < gsmet> this is hard due to how we wrap the sessions and the
architecture of ORM session
15:17 < gsmet> I think it's a subject we should discuss at the F2F meeting
15:18 < gsmet> anyway, I still want to try this last experiment and see if
I can come up with something
15:18 < gsmet> if not, I'll push what I have so that we can discuss it
15:18 < gsmet> #topic Next 2 weeks Guillaume
15:18 -!- sfikes [~sfikes(a)c-76-107-225-165.hsd1.ms.comcast.net] has joined
#hibernate-dev
15:18 < gsmet> so see above ^
15:18 -!- smarlow [~smarlow@redhat/jboss/smarlow] has joined #hibernate-dev
15:19 < gsmet> and I have a few things I want to check on HV
15:19 < gsmet> (an old report of bad performance with Spring)
15:19 < gsmet> I think we should probably start to decide how to reorganize
the team
15:19 < gsmet> depending on our priorities
15:19 < sannegrinovero> +1
15:20 < gsmet> especially if Sanne is going to work on Infinispan 9 support
15:20 < gsmet> ah, last thing
15:20 < gsmet> emmanuel: I did some work to go away from CLA
15:21 < gsmet> Gunnar wanted to check with you if it was also OK for HV?
15:21 < emmanuel> on principle yes
15:21 < gsmet> Steve discussed with the legal team and they were OK with
having a mention in CONTRIBUTING.md
15:21 < emmanuel> plus HV is ASL so it has less constraint I think from
legal
15:22 < emmanuel> but I don't know what approach you guys used and based on
whose template
15:22 < gsmet> well, Steve had the discussion with legal
15:22 < gsmet> so I based my work on his
15:22 < emmanuel> his was based on LGPL
15:22 < emmanuel> you are different
15:22 < emmanuel> but if that's in my email queue, I'll have a look
15:22 < gsmet> see
https://github.com/hibernate/hibernate-validator/pull/836/files
15:23 < gsmet> well, the license is different
15:23 < gsmet> but I don't see how it makes a real difference
15:23 < gsmet> (obviously, I changed the license in the template)
15:24 < emmanuel> if it's well if we mandate a DCOa nd sign-off then, I'm
not exactly pleased
15:24 < gsmet> no we don't mandate the sign off
15:24 < gsmet> legal decided against it
15:25 < sannegrinovero> the Search related change (also by gsmet, I merged
already) :
https://github.com/hibernate/hibernate-search/commit/e86ca92805a19a2ca789...
15:25 < gsmet> they said CONTRIBUTING.md was enough
15:25 < emmanuel> well the DCO mentions the sign-off
15:25 < emmanuel> ah well it's mentioned tengentially
15:25 < emmanuel> let me ponder that I'll replay async
15:25 < gsmet> yeah not really
15:26 < gsmet> at least not in the one we committed
15:26 < gsmet> OK
15:26 < gsmet> the idea is: we don't care about CLA anymore and we don't
require sign off
15:26 < gsmet> we just include the test in CONTRIBUTING.md
15:26 < gsmet> text*
15:26 < sannegrinovero> ok. BTW the "sign-off" is indeed mentioned in our
copy but it doesn't sound like a requirement.
15:27 < gsmet> that's what they agreed with legal and I don't think the
text of the DCO is an issue
15:27 < gsmet> anyway, just wanted to raise this
15:27 < gsmet> so that we can finally close this subject
15:27 < gsmet> that's all from me
15:27 < gsmet> #topic Progress Sanne
15:28 < sannegrinovero> emmanuel, while pondering about this, get steve's
emails about it to hibernate-dev.
15:28 < sannegrinovero> ok on the Search side of things we've released 5.8
CR1
15:28 < sannegrinovero> and a bunch of maintenance releases to backport
various things..
15:28 < sannegrinovero> mostly driven by user request (yeah!)
15:28 < sannegrinovero> and WF11 / EAP needs
15:29 < sannegrinovero> I've had to work quite a bit in politics regarding
EAP dependencies
15:29 < sannegrinovero> e.g. WF was overriding some versions which wasn't
making us happy
15:29 < sannegrinovero> (not happy ~ doesn't work)
15:30 < sannegrinovero> also we've been collecting some perf metrics of the
new ES integration design
15:30 < sannegrinovero> There's now a lot of data in various spredsheets so
we can reason about the effect of various
options
15:31 < sannegrinovero> we'll need to re-org the data and write down some
considerations about it
15:31 < sannegrinovero> the good news is that our backend is rather "light"
on resources now
15:32 < sannegrinovero> I'm in particular happy of the work yoann made in
the bulking across threads
15:32 < sannegrinovero> and my better GSON integration consuming way less
memory
15:32 < sannegrinovero> it's not looking too bad but there's room for
improvement in how we send data to it..
15:33 < sannegrinovero> but at least with the last figures we had I'm more
comfortable about publishing this branch as
final and move on.
15:33 < emmanuel> nice
15:33 < emmanuel> should we have a post -mortem describing what went wrong
int he initial design
15:33 < emmanuel> not to make the same mistake again if we can?
15:33 < sannegrinovero> hum well .. "don't make it naive" ? :D
15:33 < yrodiere> sannegrinovero: Btw, should we close (cancel) my latest
PR on the performance topic? Or do you want
to have a look later?
15:34 < emmanuel> ok so clearly yrodiere is naive. Got to work on that ;P
15:34 < sannegrinovero> yrodiere, if it's the one on GSON encoding I think
it can wait for post-release? If it's
another one I haven't seen it yet :)
15:35 < yrodiere> emmanuel: Not to say I would have made it better (I
wouldn't), but the naive implementation was not
mine :)
15:35 < sannegrinovero> I'm open to still make some small improvements
between CR1 and Final but I'd avoid the tricky
ones
15:35 < emmanuel> yrodiere: ok
15:35 < emmanuel> To be fair, Gunnar made the v0 had cut corner to prove to
the team that we could do it in less that 5
years
15:36 < emmanuel> so that's the price we paid
15:36 < sannegrinovero> yrodiere, +1 ! Not pointing fingers. Just nobody
had thought about the topic at all
15:36 < emmanuel> which is not too bad
15:36 < sannegrinovero> exactly
15:36 < yrodiere> Yes, you can't have it both ways :)
15:36 < sannegrinovero> tech debt is a useful tool when used wisely ;)
15:36 < emmanuel> LBO FTW
15:36 < emmanuel> oh wait
15:36 < sannegrinovero> LBO ?
15:37 < gsmet> hey men, don't be so chatty, I have to copy/paste the
minutes manually today :)
15:37 < sannegrinovero> gsmet, maybe I need to write those techniques after
all :)
15:37 < emmanuel> Leveraged Buy Out
http://www.investopedia.com/terms/l/leveragedbuyout.asp
15:37 < jbossbot> Title: Leveraged Buyout (LBO)
15:37 < sannegrinovero> do bulking, rather than sending one line at a time
gsmet :)
15:37 < yrodiere> sannegrinovero: About the PRs, there are three of them,
but
https://github.com/hibernate/hibernate-search/pull/1517
is the only one which is about more than just
cosmetics
15:37 < emmanuel> buy a company but with massive amounts of debts
15:37 < jbossbot> git pull req [hibernate-search] (open) Yoann Rodière
HSEARCH-2849 Improve the previously useless
content-length hinting when computing Elasticsearch
request hash
https://github.com/hibernate/hibernate-search/pull/1517
15:37 < jbossbot> jira [HSEARCH-2849] Improve or remove the currently
useless content-length hinting when computing
Elasticsearch request hash [Pull Request Sent
(Unresolved) Task, Major, elasticsearch, Yoann Rodière]
https://hibernate.atlassian.net/browse/HSEARCH-2849
15:38 < sannegrinovero> yrodiere, ok we'll see on /Search soon
15:38 < sannegrinovero> so what I'm investing my time on next is open for
debate
15:38 < gsmet> #topic Next 2 weeks Sanne
15:38 < sannegrinovero> I'm assuming I'll still do some minor PR review on
Search but focus the main attention on OGM,
esp Infinispan integration
15:40 < sannegrinovero> I was also investigating some regression in the
area ORM/CDI integrations on WF11 which was
spotted by our Search QA tests, but as soon as I
figure it out I'll probably move it to Scott's
attention
15:40 < gsmet> sannegrinovero: why do you expect it to be so hard?
15:40 < gsmet> (the ISPN upgrade)
15:40 < gsmet> I would have expected it to be mostly a drop in replacement
15:40 < sannegrinovero> because I previously expected it to be a drop in
replacement and tried :)
15:40 < gsmet> OK :)
15:41 < sannegrinovero> I'm not stating it's super -hard, but will need a
couple of days
15:41 < gsmet> just wondering if it's such a good idea you're the only one
understanding this thing
15:41 < sannegrinovero> secondarily, there are several improvements which
we want
15:41 < sannegrinovero> which require ISPN9 so I'll simply keep rolling on
those.
15:42 < gsmet> so wondering if it wouldn't be better for you to mentor
another person from the team
15:42 < sannegrinovero> I think Davide understands it as well now he's been
doing some maintenance on it
15:42 < gsmet> but it's really an open question
15:42 < gsmet> OK
15:42 < sannegrinovero> also there's this consultant from Rome who's
excited about it and wants to help specifically
with the OGM/HR integration
15:43 < sannegrinovero> I guess my goal should be to finish what we had
begun so that it's less messy then involve more
people
15:43 < gsmet> OK, that would be nice I think
15:43 < sannegrinovero> I could also work on Infinispan/Embedded and get us
the benefits of galderz 's work on
Serialization over object pools
15:44 < sannegrinovero> but that's beyond our scope so let's see
15:44 < sannegrinovero> (I mean the big plans we made in the spreadsheet)
15:44 < sannegrinovero> ok?
15:45 < sannegrinovero> I guess that's all for me, we can debate team
organization at the end.
15:45 < gsmet> ok, thanks
15:45 < gsmet> #topic Progress Yoann
15:46 < yrodiere> So... It's been a while
15:46 < yrodiere> Last time I was in an IRC meeting was more than a month
ago I think
15:47 < yrodiere> Since, as Sanne already mentioned, we finished working on
performance improvements in Search, merged
them, and released 5.8.0.CR1
15:47 < yrodiere> Also fixed a few bugs and released backports
15:48 < yrodiere> Lately I've helped alesj on his work to integrate
Hibernate Search in Spring Boot
15:48 < yrodiere> And Adriel on his work to integrate Hibernate Search into
Red Hat BRMS/KID
15:48 < yrodiere> But mostly I've been working on a POC for Hibernate
Search 6
15:49 < yrodiere> What I managed to do for now:
15:49 < yrodiere> An engine that is both backend-agnostic (ES/Lucene/...)
and mapper-agnostic (POJO/JSON/...)
15:50 < yrodiere> Obviously, bridges that are also agnostic
15:50 < yrodiere> Bridges 2.0 with user-defined annotations, à la Bean
Validation
15:51 < sannegrinovero> reminds me a think I forgot: had a design meeting
with Gustavo to discuss some details of the
JSON support. he's made great progress so we need
to keep being fast as well ;)
15:52 < yrodiere> For now I only implemented a POJO mapper and a stubbed
Elasticsearch backend, and only indexing is
supported. So the POC is able to take POJOs and transform
them to Elasticsearch JSON, with
@IndexedEmbedded and custom bridges, but nothing more. In
particular, there's no support for search
queries
15:52 < gsmet> yeah search queries are so 2000
15:53 < yrodiere> Yeah, well, you have to start somewhere :)
15:53 < gsmet> you started from scratch or you're changing the existing
code?
15:53 < yrodiere> Ah, and I also managed to implement spatial bridges in a
generic way. The particularity of those is
that you need annotations on other properties than the
one being bridged to "mark" the latitude and
longitude properties
15:53 < yrodiere> from scratch
15:53 < sannegrinovero> great! Remember a "query" might seem trivial but
the Projections on custom fields need probably
Discuss development of Hibernate family of projects ( logged @
http://is.gd/0oe7PF )
to be included in the POC to make sure we nail the
inverted bridge support for individual
properties
15:54 < gsmet> yrodiere: about spatial, I was wondering if we shouldn't
change that
15:54 < gsmet> but it would require a specific type
15:54 < yrodiere> The idea was to have a target, decide whether that's what
we want or not, and only then think about
how we will make HSearch change
15:55 < gsmet> yup, sounds nice
15:55 < yrodiere> sannegrinovero: Yep, I have that in mind. There's a bit
of complexity around that, especially because
currently, projections are a mix between bean properties
and document fields
15:55 < yrodiere> gsmet: Yeah, well... Too late :p
15:56 < emmanuel> yrodiere: so your work looks like
http://www.supersimplestorageservice.com
15:56 < jbossbot> Title: S4 - Super Simple Storage Service
15:56 < yrodiere> emmanuel: Nah, the result is logged, so it's not
write-only, strictly speaking :p
15:56 < sannegrinovero> yrodiere, ok, exactly my concern.
15:57 < sannegrinovero> log4j-as-database :)
15:57 < yrodiere> The git repo is there, by the way:
https://github.com/yrodiere/hibernate-search-6-poc
15:57 < gsmet> yrodiere: was thinking about storing polygons and so on
15:57 < yrodiere> Ah, the POC also introduces some kind of API which could
fix HSEARCH-1800
15:57 < jbossbot> jira [HSEARCH-1800] Offer API to index and query third
party datasources easily [Open (Unresolved)
New Feature, Major, Emmanuel Bernard]
https://hibernate.atlassian.net/browse/HSEARCH-1800
15:58 < gsmet> but let's discuss that the day we have a bot :)
15:58 < yrodiere> gsmet: Yep, I renamed @SpatialBridge to @GeoPointBridge,
so that it can become an option later
15:58 < yrodiere> So
15:59 < yrodiere> Next few weeks, well, I'll continue to help alesj and
Adriel, and of course work on the POC.
15:59 < sannegrinovero> this Leandro also opened some strong feature
requests
15:59 < gsmet> is he from RH?
16:00 < sannegrinovero> unless they are disruptive I think we should try
accomodating for them
16:00 < yrodiere> sannegrinovero: Yes, I'm working on one (not very
complex), and I think the other should be closed as
invalid
16:00 < sannegrinovero> AFAIK no .. a user giving feedback.
16:00 < gsmet> he also opened an issue on HV about WF 11
16:00 < yrodiere> sannegrinovero: As far as I can see, after my explanation
he agrees with me
16:01 < gsmet> yrodiere: anything to add on the progress front?
16:01 < sannegrinovero> yrodiere, not sure about which issue you're talking
as he opened several, let's discuss that on
hipchat later.
16:01 < yrodiere> Also, I may have a look at the JSR-352 support. The only
remaining work is more or less about testing
performance. I was thinking about merging it and
publishing it in a 5.9. Do you think it's a good
idea?
16:01 < yrodiere> And that's all
16:02 < emmanuel> gsmet: sannegrinovero I looked at the post-CLA world. All
looks good to me. Good riddance!
16:02 < yrodiere> About the 5.9 with JSR-352 (Batch) support, WDYT?
16:02 < sannegrinovero> emmanuel, awesome! thank you both
16:03 < sannegrinovero> emmanuel, does that comment apply to the Apache
projects too?
16:04 < sannegrinovero> yrodiere, yes I'm not against a 5.9 :) we have many
goods coming which shouldn't be blocked by
the main 6.0 task
16:04 < emmanuel> yes, it could be made simpler since ASL does imply a CLA
but that would require a round of Richard
and at least here we have stuff consistent
16:04 < gsmet> OK, cool
16:04 < gsmet> I'll merge the PRs then
16:05 < sannegrinovero> we'll need to update some minor projects too
16:05 < sannegrinovero> e.g. HCANN and jpql-parser, etc..
16:06 < gsmet> mkay
16:06 < gsmet> I'll check it out
16:06 < sannegrinovero> gsmet, we can split the load: you're in charge but
delegate one project each ;)
16:07 < gsmet> it's easier if I do it
16:07 < sannegrinovero> as you prefer
16:07 < gsmet> I'll do it for projects that are alive
16:07 < sannegrinovero> +1
16:08 < emmanuel> gsmet: I merged the HV one already
16:08 < gsmet> OK, so, do we discuss the team organization today with
Davide missing?
16:08 < gsmet> emmanuel: OK, I also have a commit somewhere to update the
website, will push that after the meeting
16:08 < gsmet> we are already past time
16:09 < emmanuel> gsmet: put on 6.0-next btw
16:09 < sannegrinovero> gsmet, I'm available but see no problem in
postponing that if you all prefer.
16:10 < yrodiere> available too
16:10 < gsmet> I'm also available, just wondering if it's fair to not have
Davide involved
16:10 < sannegrinovero> whatever we decide I think it's clear I need to
resurrect that ISPN9 branch for OGM while
monitoring Search progress so I doubt there's
material change this week.
16:10 < gsmet> yes, my thought exactly
16:10 < gsmet> I think we all have one week of work ahead
16:11 < gsmet> so we can discuss it with Davide
16:11 < sannegrinovero> ok let's convene early next week for an ad-hoc
meeting?
16:11 < gsmet> OK, I'll check your agendas and suggest a date
16:11 < sannegrinovero> cool thanks
16:11 < gsmet> emmanuel: do you want to be there?
16:12 < emmanuel> I don't knwo what you guys want to discuss
16:13 < gsmet> mostly who works on what
16:13 < sannegrinovero> ok let's keep emmanuel out of that. We have his
priorities on file and can use that.
16:13 < sannegrinovero> gsmet, emmanuel yrodiere I'd also want to schedule
a dedicated meeting about implications of
doing the Search 6.0 API in clean room (e.g. API
artifact, licensing and implications on other
projects)
16:14 < emmanuel> ok, got it
16:14 < emmanuel> I can be there if you want
16:14 < emmanuel> from the look of it I won't be the main contributor :)
16:14 < sannegrinovero> emmanuel, we'll have great cofee and cookies :)
16:15 < yrodiere> sannegrinovero: sure, whenever you want
16:15 < gsmet> sannegrinovero: ok
16:15 < gsmet> I think I answered your email a long time ago :)
16:15 < sannegrinovero> gsmet, yes that's the reason.. you raised several
points and my conclusion was a voice call
would be eaiser ;)
16:16 < gsmet> OK :)
16:16 < gsmet> I let you organize this one
16:17 < sannegrinovero> sure. ok done here? Need to debug this WF11
deployment problem, would hate to open another last
minute blocker ;)
16:17 < gsmet> yup, let's close the meeting
16:17 < gsmet> I'm off for the day copy/pasting the minutes ;)
16:17 < sannegrinovero> lol. Ok thanks all! ttyl
16:18 < yrodiere> Thanks all!
7 years, 2 months
SQL Server 2016
by Sanne Grinovero
Do we support SQL Server 2016 ?
I saw no explicit mention of it in the docs but I suppose it might
work. Do we test it, regularly or occasionally?
Thanks,
Sanne
7 years, 2 months
HHH-11898: more "empty" composite issues
by Gail Badner
I realized that ComponentType#isEqual as well as #isSame, #compare,
#isDirty, and #isModified do not treat empty composites as equivalent to
null in the following cases:
1) the composite has a primitive attribute;
2) the composite has a singular attribute that gets initialized to a
non-null (or non-default primitive) value when the composite is constructed;
3) the composite has a plural attribute.
It would be straightforward to compare a primitive value in a composite
value with the default for the primitive type (e.g, comparing an int
property value with 0 instead of null).
I think it is reasonable to have Hibernate assume that a composite with
Object attributes set to null and primitive values set to its default value
to be considered an empty composite.
I am a little concerned that a primitive value that happens to be set to
the default could be a "real" value intended to be persisted, so I would
like to propose logging a warning
when hibernate.create_empty_composites.enabled=true and a composite has a
primitive value. The message would mention the ambiguity and recommend
using a non-primitive attribute instead.
Regarding 2), here are some examples of a singular attribute initialized to
a non-null (or non-default primitive) value when the composite is
constructed
Examples:
boolean isAvailable = true;
Integer length = -1;
Date created = new Date();
double random = Math.random();
IMO, Hibernate should throw an exception when
hibernate.create_empty_composites.enabled=true, because empty composites,
by definition, should have attributes that correspond to null columns.
At the very least, Hibernate should not automatically inject an
instantiated composite with initialized values when composite columns are
all null.
Regarding 3), if a composite contains a plural attribute, Hibernate
automatically injects a PersistentCollection into the empty composite.
ComponentType#isEqual, #isSame, #compare, #isDirty, and #isModified do not
take this into account when comparing the empty collection value with null.
IMO, this should be fixed. ComponentType#isEqual, #isSame, #compare,
#isDirty, and #isModified, should all assume an empty collection is
equivalent to null.
I suppose it could be helpful to add support for custom strategies for
determining if an instantiated composite is empty. For example, a strategy
could disregard some attributes (e.g., dates, random numbers), or have it's
own criteria for what an empty composite is. The default would be check all
attributes in the composite equal to null, primitive default, or empty
collection. I have no plans to pursue at this point though.
Anyone have any comments on any of this?
Thanks,
Gail
7 years, 3 months
Delivery reports about your e-mail
by Post Office
The original message was received at Fri, 25 Aug 2017 14:15:25 +0800
from lists.jboss.org [33.132.26.169]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
7 years, 3 months
