Hibernate ORM Docbook removal
by Vlad Mihalcea
Hi,
Since it's more than one year since we switched to Asciidoc, I think we
should remove the docbook folder.
Does anyone has anything against it or thinks this is not a good idea?
Vlad
8 years, 2 months
[HV] Hibernate Validator 6 benchmark updates
by Guillaume Smet
Hi,
So, as we are leaning towards final, I made another round of benchmarking
on HV 6.
They are run on the same machine as the previous "Hibernate Validator 6
benchmarks results" I posted a few months ago [1] so they can be compared
to these numbers (you'll notice the 5.4.1 numbers are about the same
between the 2 emails).
Note that these benchmarks only exercises the validation engine but does
not report any violation.
I think I'll add some more benchmarks to ensure violation reporting also
moves in the right direction.
It might also be a good occasion to revisit this benchmark:
http://carinae.net/2010/06/benchmarking-hibernate-validator-and-apache-be...
. With a large value of "revisit" as it's really basic but the scenarios
are interesting. Note that I'm a bit pessimistic on the parsing part: we
now do a lot more work than before to deal with container elements so the
startup cost will probably be significantly higher.
== Apache BVal 1.1.2
Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
357.500 ±(99.9%) 5.327 ops/ms [Average]
(min, avg, max) = (337.100, 357.500, 381.472), stdev = 10.760
CI (99.9%): [352.173, 362.827] (assumes normal distribution)
Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
379.605 ±(99.9%) 5.817 ops/ms [Average]
(min, avg, max) = (360.654, 379.605, 411.361), stdev = 11.750
CI (99.9%): [373.789, 385.422] (assumes normal distribution)
(not really clear how BVal happens to be faster in the cascaded validation
case)
== HV 5.4.1.Final
Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
558.196 ±(99.9%) 3.643 ops/ms [Average]
(min, avg, max) = (542.396, 558.196, 575.360), stdev = 7.360
CI (99.9%): [554.552, 561.839] (assumes normal distribution)
Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
285.788 ±(99.9%) 1.970 ops/ms [Average]
(min, avg, max) = (278.611, 285.788, 298.530), stdev = 3.980
CI (99.9%): [283.817, 287.758] (assumes normal distribution)
== Master from March after the first round of improvements (numbers taken
from the previous email)
Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
869.546 ±(99.9%) 14.734 ops/ms [Average]
(min, avg, max) = (760.007, 869.546, 909.206), stdev = 29.763
CI (99.9%): [854.813, 884.280] (assumes normal distribution)
Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
343.699 ±(99.9%) 2.077 ops/ms [Average]
(min, avg, max) = (331.333, 343.699, 352.626), stdev = 4.196
CI (99.9%): [341.622, 345.776] (assumes normal distribution)
== HV 6 - Current master with
https://github.com/hibernate/hibernate-validator/pull/814 applied
Result
"org.hibernate.validator.performance.simple.SimpleValidation.testSimpleBeanValidation":
924.121 ±(99.9%) 3.686 ops/ms [Average]
(min, avg, max) = (905.423, 924.121, 941.295), stdev = 7.446
CI (99.9%): [920.435, 927.807] (assumes normal distribution)
Result
"org.hibernate.validator.performance.cascaded.CascadedValidation.testCascadedValidation":
430.092 ±(99.9%) 3.661 ops/ms [Average]
(min, avg, max) = (416.439, 430.092, 447.607), stdev = 7.396
CI (99.9%): [426.431, 433.754] (assumes normal distribution)
== Conclusion
The good news is that the results are even better than the ones from March,
after some further tweaking.
We are significantly faster than BVal in these scenarios and also
significantly faster than 5.4.1.Final.
Now, we need to get this PR in :).
[1] http://lists.jboss.org/pipermail/hibernate-dev/2017-March/016057.html
8 years, 2 months
progress update on wildfly-nosql project...
by Scott Marlow
Hi,
Wildfly Swarm now has the initial NoSQL (native NoSQL driver
integration) fractions included [1], which should be in the next Swarm
release.
Applications can use @Inject @Named("MyDefinedNoSQLProfile") Cluster
myCassandraCluster; to inject native NoSQL connections, where the
injected connection class is shared with other applications (e.g. the
native NoSQL driver code is currently responsible for the connection
pooling).
The next step will be to enable MongoDB, Cassandra, Neo4j, OrientDB
testing in the Swarm CI (Jenkins) environment. Perhaps via Docker
(will need to install that). Does OGM CI use Docker?
Is OGM-1287 still the best solution for OGM to access NoSQL
connections on WildFly/WildFly-Swarm? When we last talked, the OGM
team didn't want to depend on a wildfly-nosql (subsystem) SPI for
obtaining NoSQL connections, so using something like OGM-1287 could
work. What do you think?
Scott
[1] https://groups.google.com/forum/?utm_medium=email&utm_source=footer#!topi...
8 years, 2 months
Hibernate NoORM IRC meeting minutes
by Guillaume Smet
Hi,
So, apparently, today, the bot was at the beach with Gunnar and Sanne.
Anyway, here is the plain text log of the meeting:
15:00 < gsmet> #startmeeting
15:01 < gsmet> hmmm, am I on the wrong channel or is the bot not there?
15:01 -!- DavideD [~DavideD(a)149.11.102.74] has joined #hibernate-dev
15:01 < gsmet> @da
15:01 < yrodiere> right channel
15:01 < gsmet> DavideD: hi! Do you know how we can have the bot coming?
15:01 < DavideD> close enough
15:01 < gsmet> looks like it's not there
15:01 < DavideD> no idea
15:02 < gsmet> mmmh, Ok, so I suppose I'll copy paste the meeting
15:02 < gsmet> #topic Progress Davide
15:02 < DavideD> I cannot see the history, #startmeeting didn't work?
15:02 < gsmet> the bot is not there
15:03 < gsmet> and yeah, #startmeeting didn't work
15:03 < DavideD> I'm working on fixing a bug in OGM
15:03 < gsmet> the one reported the other day?
15:03 < DavideD> in Neo4j we loose some associations when reading them
15:03 < gsmet> about missing properties?
15:03 < DavideD> That's going to be the next one
15:04 < DavideD> this is related to the previous PR from the contributor
15:04 < gsmet> ah ok
15:04 -!- anistor [~adrian@redhat/jboss/anistor] has joined #hibernate-dev
15:04 < DavideD> It can happen during recursive associations on the same
entities
15:04 < DavideD> but in other cases as well
15:05 < gsmet> OK, it's weird we didn't notice it before
15:05 < gsmet> but nice to have it on the radar now
15:05 < DavideD> Yes, I think I fix it but I'm writing addional tests to
cover it
15:06 < gsmet> OK, cool
15:06 < gsmet> and it was only for Neo4j?
15:06 < DavideD> It happens when you have to separate entities that refers
to a third entity using the same name for the property
15:06 < DavideD> It's a bit specific and I think we didn't test it before
15:06 < gsmet> OK
15:06 < DavideD> MongoDB throws a NullPointer :/
15:07 < gsmet> wouhou
15:07 < DavideD> This last one is weird and I still haven't completely
figure it out
15:07 < gsmet> so, considering these bugs, it might definitely be nice to
release something once they're fixed
15:07 < DavideD> Yes, I would like to release once they are done
15:08 < DavideD> This is what I'm going to do this week I guess
15:08 < gsmet> cool, Sanne will be happy :)
15:08 < DavideD> I also need to take some time to check MariaDB on CI
15:08 < DavideD> and update the JDK 9
15:09 < gsmet> IIRC, there are some issues with this one
15:09 < DavideD> It seems there are some configuration issue
15:09 < gsmet> in the Maven plugins
15:09 < gsmet> javadoc and such
15:09 < gsmet> they are parsing the Java version in an incorrect way
15:09 < gsmet> Gunnar has the specifics, we better check with him before
upgrading and breaking everything
15:10 < DavideD> Ah, OK, well I can install it and we can upgrade later
when you are ready
15:10 < gsmet> we should upgrade the faulty plugins everywhere before
switching
15:10 < gsmet> yes, that would be better
15:10 < DavideD> I think that's all from me
15:10 -!- smarlow [~smarlow@redhat/jboss/smarlow] has joined #hibernate-dev
15:10 < gsmet> let's sync with Gunnar when he's back from Crete
15:11 < gsmet> thanks!
15:11 < gsmet> #topic Progress Guillaume
15:11 < gsmet> so we submitted BV 2 to the Final Approval Ballot
15:11 < gsmet> and the RI
15:11 < gsmet> I am now working on 2 fronts:
15:12 < gsmet> - updating the documentation
15:12 < gsmet> - benchmarking and improving the performance and memory
footprint of the RI
15:12 < gsmet> the first task is for 6.0.0
15:13 < gsmet> the second one for 6.0.1
15:13 < gsmet> I had a bad surprise yesterday as I think there's a minor
issue in the TCK
15:13 < gsmet> it's a one letter change but I'm wondering if it will cause
some issue or not
15:13 < gsmet> need to clarify that with Gunnar
15:14 < gsmet> not very happy about it :/
15:14 < gsmet> #topic Next 2 weeks Guillaume
15:14 < DavideD> One letter change?
15:14 < gsmet> yeah
15:14 < gsmet> it's referring the wrong class in the hierarchy
15:14 < DavideD> Ah, nasty
15:14 < gsmet> the change is something like IWrapper211 -> IWrapper21
15:15 < gsmet> it was working before as HV was not that correct about it
15:15 < gsmet> but it's not very clear either as it's a bit of a corner case
15:15 < gsmet> so we have 3 possibilities:
15:15 < gsmet> - fix the issue in the TCK and be happy
15:16 < gsmet> - fix the issue in the TCK and clarify the spec
15:16 < gsmet> - or throw away what I did in the RI :)
15:16 < gsmet> it's some performance improvements but they are rather
important
15:16 < gsmet> so it wouldn't be a good thing
15:16 < gsmet> anyway, will see that with Gunnar
15:17 < gsmet> so back to the future!
15:17 < gsmet> I'm on vacation at the end of the week
15:17 < gsmet> only for a week
15:17 < gsmet> I think I'll continue the work I started for the end of the
week
15:18 < gsmet> would like to have everything submitted before the end of
the week
15:18 < gsmet> that's pretty much it for me
15:18 < gsmet> #topic Progress Yoann
15:18 < yrodiere> So...
15:20 < yrodiere> I've been revamping the way we orchestrate works in the
Elasticsearch backend, so that we are fully reactive and most of all so
that it's easier to change how works are executed (in parallel
or serially, synchronously or asynchronously, bulking
works together from different changesets or not, ...)
15:20 < gsmet> you forgot "randomly"
15:20 < yrodiere> This has other side benefits, such as a more precise
error handling (you won't cancel subsequent changesets just because a
previous changeset failed)
15:21 < yrodiere> gsmet: that's "in parallel" :p
15:21 < yrodiere> anyway, it's been much longer than expected, but I'm
finally seeing the end, I'm mostly working on making the commits a bit
smaller
15:22 < yrodiere> I've also been working on performance tests, which have
been merged and improved thanks to Sanne
15:22 < yrodiere> Next...
15:23 < gsmet> #topic Next 2 weeks Yoann
15:23 < yrodiere> I'll try to play around with the performance tests and
the orchestration in order to find out a sweet spot
15:24 < gsmet> so this is pre 5.8 work?
15:24 < gsmet> you want to include the improvements in 5.8?
15:24 < yrodiere> Yeah. Basically we had several reports that performance
is terrible
15:25 -!- antoine_sd is now known as asd_away
15:25 < yrodiere> I'll also look for problems in our code (computationally
intensive or memory intensive code) but I don't have much hope on this side
15:26 < yrodiere> (mainly because in some cases, the way we do things is
way too complex but we simply have to)
15:26 < yrodiere> Hopefully we will be able to improve a bit more on this
side in 6
15:26 < yrodiere> I'll have a look anyway.
15:26 < gsmet> yeah, it's interesting
15:26 < gsmet> btw, I recommend YKP over visualvm
15:27 < gsmet> I'm playing with it right now and it's really nice
15:27 < yrodiere> Sanne told me about flightrecorder
15:27 -!- jbossbot [~jbossbot@redhat/jbossbot] has joined #hibernate-dev
15:27 -!- kkhan [~kkhan@redhat/jboss/kkhan] has quit [Quit: My MacBook has
gone to sleep. ZZZzzz…]
15:27 < yrodiere> It seems we're eligible for the "free" (as in free beer)
license
15:27 < yrodiere> as long as we don't work on customer cases
15:27 -!- kkhan [~kkhan@redhat/jboss/kkhan] has joined #hibernate-dev
15:28 < gsmet> OK, I should probably also take a look to this one
15:28 < gsmet> right now I'm working on memory snapshot and YKP is really
nice to use
15:29 < yrodiere> I may have a look, but I must admit I'm not looking
forward to having to mess with DRM
15:29 < gsmet> DRM?
15:29 -!- kkhan_ [~kkhan@redhat/jboss/kkhan] has joined #hibernate-dev
15:29 -!- kkhan [~kkhan@redhat/jboss/kkhan] has quit [Read error:
Connection reset by peer]
15:29 < yrodiere> Well you license thing, I suppose the software stops
working unless you give it some key
15:29 < gsmet> the bot is back, let's do the meeting again!
15:30 < gsmet> yeah, I'll check that
15:30 < gsmet> but anyway, I think we could apply for an Open Source
license for the Hibernate projects
15:30 < yrodiere> anyway, that's all from me
15:30 < gsmet> we need to add some logo on the website though
15:30 < gsmet> cool, thanks!
15:31 < gsmet> anything else or should we close the meeting?
15:31 < gsmet> (nothing from me)
15:31 < yrodiere> nothing here
15:32 < gsmet> DavideD: ?
15:32 < DavideD> nothing
15:32 < gsmet> OK, let's close then, thanks everyone
15:32 < gsmet> #endmeeting
8 years, 2 months
Replacement for SessionFactoryImplementor#getClassMetadata ?
by Sanne Grinovero
Hi all,
Hibernate Search is using this method, but it's deprecated with the
following comment:
"Use the descriptors from #getMetamodel() instead".
I'm a bit lost about how to reach the same by using the Metamodel.
I found this solution:
SessionFactoryImplementor sfi =..
ClassMetadata cm = (ClassMetadata) sfi.getMetamodel().entityPersister( x );
But it's requiring a suspicious casting, which I was hoping to avoid
as I'm already working at SPI level?
My goal is to ultimately read
`ClassMetadata#getIdentifierPropertyName()`. Maybe there's a better
approach?
Thanks,
Sanne
8 years, 2 months
