Hibernate in the JBoss Community Recognition Awards
by Brett Meyer
The Hibernate community has multiple contributors nominated for the 2013 JBoss Community Recognition Awards. Please take a moment and vote!
https://www.jboss.org/jbcra/vote.html
>From the nomination introductions, in no particular order:
Guillaume Smet - Guillaume Smet has been thoroughly testing Hibernate Search, and providing many critical fixes. His contributions have been priceless and he also regularly contributes to the mailing list with great advice. Not least, he motivates us all to put the quality bar higher at every release.
Łukasz Antoniak - Łukasz is always willing to dig in and tackle difficult issues spanning a *wide* breadth of topics -- especially ones outside the scope of his typical expertise. His help in resolving many issues in the Hibernate database testing matrix really illustrates how reliably amazingly his contributions have been. These were mostly databases where we could not offer him the greatest tooling (often not even database access to databases being tested). Those were contributions that directly affected Hibernate and EAP timelines in very positive ways. And all of that in addition to maintaining Envers...
Guillaume Scheibel looks like a full time Hibernate team member. He has been leading the development for the MongoDB GridDialect for Hibernate OGM, developed most of it himself, and participates in design decisions. The need for Hibernate OGM to have a MongoDB/Infinispan integration to complete query support was reason enough for him to implement one and contribute it to Infinispan. Not least, he presented the project at JUG events!
Nicolas Helleringer - Nicolas proposed a great new feature to the Hibernate Search project: spatial queries and proximity filtering. He lead the design of it in the most collaborative way with the team, donated his expertise in spatial coordinates handling, spent months to implement it and polish it considering feedback from the whole community, and a year later is still actively helping new users with it, improving documentation and taking ownership of bug reports.
Tim Ward - Tim's expertise, help, advice and support were instrumental in getting OSGi support into Hibernate. As an Apache Aries PMC member and Enterprise OSGi advocate, Tim has a wealth of knowledge; but his patience and knack for doing a *great* job at explaining the concepts were what made him truly amazing to work with. Without Tim's help OSGi support in Hibernate would still be a talking point rather than an implemented reality.
Brett Meyer
Red Hat Software Engineer, Hibernate
10 years, 10 months
DocumentBuilder refactoring in Hibernate Search: how to deal (internally) with metadata
by Sanne Grinovero
We're starting a series of refactorings in Hibernate Search to improve
how we handle the entity mapping to the index; to summarize goals:
1# Expose the Metadata as API
We need to expose it because:
a - OGM needs to be able to read this metadata to produce appropriate queries
b - Advanced users have expressed the need to for things like listing
all indexed entities to integrate external tools, code generation,
etc..
c - All users (advanced and not) have interest in -at least- logging
the field structure to help creating Queries; today people need a
debugger or Luke.
Personally I think we end up needing this just as an SPI: that might
be good for cases {a,b}, and I have an alternative proposal for {c}
described below.
However we expose it, I think we agree this should be a read-only
structure built as a second phase after the model is consumed from
(annotations / programmatic API / jandex / auto-generated by OGM). It
would also be good to keep it "minimal" in terms of memory cost, so to
either:
- drop references to the source structure
- not holding on it at all, building the Metadata on demand (!)
(Assuming we can build it from a more obscure internal representation
I'll describe next).
Whatever the final implementation will actually do to store this
metadata, for now the priority is to define the contract for the sake
of OGM so I'm not too concerned on the two phase buildup and how
references are handled internally - but let's discuss the options
already.
2# Better fit Lucene 4 / High performance
There are some small performance oriented optimizations that we could
already do with Lucene 3, but where unlikely to be worth the effort;
for example reusing Field instances and pre-intern all field names.
These considerations however are practically mandatory with Lucene 4, as:
- the cost of *not* doing as Lucene wants is higher (runtime field
creation is more expensive now)
- the performance benefit of following the Lucene expectations are
significantly higher (takes advantage of several new features)
- code is much more complex if we don't do it
3# MutableSearchFactory
Let's not forget we also have a MutableSearchFactory to maintain: new
entities could be added at any time so if we drop the original
metadata we need to be able to build a new (read-only) one from the
current state.
4# Finally some cleanups in AbstractDocumentBuilder
This class served us well, but has grown too much over time.
Things we wanted but where too hard to do so far:
- Separate annotation reading from Document building. Separate
validity checks too.
- It checks for JPA @Id using reflection as it might not be available
-> pluggable?
- LuceneOptionsImpl are built at runtime each time we need one ->
reuse them, coupling them to their field
DocumentBuilderIndexedEntity specific:
- A ConversionContext tracks progress on each field by push/pop a
navigation stack to eventually thrown an exception with the correct
description. If instead we used a recursive function, there would be
no need to track anything.
- We had issues with "forgetting" to initialize a collection before
trying to index it (HSEARCH-1245, HSEARCH-1240, ..)
- We need a reliable way to track which field names are created, and
from which bridge they are originating (including custom bridges:
HSEARCH-904)
- If we could know in advance which properties of the entities need
to be initialized for a complete Document to be created we could
generate more efficient queries at entity initialization time, or at
MassIndexing select time. I think users really would expect such a
clever integration with ORM (HSEARCH-1235)
== Solution ? ==
Now let's assume that we can build this as a recursive structure which
accepts a generic visitor.
One could "visit" the structure with a static collector to:
- discover which fields are written - and at the same time collect
information about specific options used on them
-> query validation
-> logging the mapping
-> connect to some tooling
- split the needed properties graph into optimised loading SQL or
auto-generated fetch profiles; ideally taking into account 2nd level
cache options from ORM (which means this visitor resides in the
hibernate-search-orm module, not engine! so note the dependency
inversion).
- visit it with a non-static collector to initialize all needed
properties of an input Entity
- visit it to build a Document of an initialized input Entity
- visit it to build something which gets feeded into a non-Lucene
output !! (ElasticSearch or Solr client value objects: HSEARCH-1188)
.. define the Analyzer mapping, generate the dynamic boosting
values, etc.. each one could be a separate, clean, concern.
This would also make it easier to implement a whole crop of feature
requests we have about improving the @IndexedEmbedded(includePaths)
feature, and the ones I like most:
# easy tool integration for inspection
# better testability of how we create this metadata
# could make a "visualizing" visitor to actually show how a test
entity is transformed and make it easier to understand why it's
matching a query (or not).
Quite related, what does everybody think of this :
https://hibernate.atlassian.net/browse/HSEARCH-438 Support runtime
polymorphism on associations (instead of defining the indexed
properties based on the returned type)
?
Personally I think the we should support that, but it's a significant
change. I'm bringing that up again as I suspect it would affect the
design of the changes proposed above.
This might sound a big change; in fact I agree it's a significant
style change but it is rewriting what is defined today in just 3
classes; no doubt we'll get more than a dozen ouf of it, but I think
it would be better to handle in the long run, more flexible and
potentially more efficient too.
Do we all agree on this? In practical terms we'd also need to define
how far Hardy wants to go with this, if he wants to deal only with the
Metadata API/SPI aspect and then I could apply the rest, or if he
wants to try doing it all in one go. I don't think we can start
working in parallel on this ;-)
[sorry I tried to keep it short.. then I run out of time]
Sanne
10 years, 10 months
hibernate-delta
by Gregor Zeitlinger
Hi,
I've created https://github.com/txtr/hibernate-delta because I couldn't
find a solution that would generate SQL update statements based on the
fields that I added to my @Entity.
The trick is that it stores the schema in an XML file that is commited
to git. That way, you only get the differences you introduced.
It can also find the differences between your XML schema and the actual
database (using liquibase).
Now the questions
1. Is this something that already exists?
2. Is somebody interested in growing this from the current setup
(tested with Oracle only)?
3. Would this maybe even a candidate to include in hibernate tools?
--
Gregor Zeitlinger
gregor.zeitlinger(a)txtr.com
10 years, 10 months
Gradle subproject dependency question
by Brett Meyer
For OSGi testing, I have a new bundle underneath hibernate-osgi:
hibernate-orm
build.gradle
settings.gradle
hibernate-osgi
hibernate-osgi.gradle
test-client-bundle
build.gradle
test-client-bundle depends on an interface in hibernate-osgi's test sourceSet. Originally, I was trying to avoid adding test-client-bundle to the root project & settings.gradle. However, is there any other way for test-client-bundle to be 1.) built before hibernate-osgi:test and 2.) depend on hibernate-osgi test classes? Is there a typical convention that I've overlooked?
Brett Meyer
Red Hat Software Engineer, Hibernate
+1 260.349.5732
10 years, 10 months
Fwd: [jdf-dev] JBoss Modules dependency vs pain POM dependency + exclusions
by Emmanuel Bernard
Below is an email describing the issues i had to get Hibernate Search run in WildFly / EAP. A possibility to make life easier for Hibernate Search users in WildFly is as described by Pete to create a hibernate-search-orm-wildfly which marks Hibernate ORM as provided.
What do you think?
Emmanuel
Begin forwarded message:
> From: Pete Muir <pmuir(a)redhat.com>
> Date: 6 juin 2013 11:21:13 UTC+02:00
> To: Emmanuel Bernard <emmanuel(a)hibernate.org>
> Cc: jdf-dev(a)lists.jboss.org
> Subject: Re: [jdf-dev] JBoss Modules dependency vs pain POM dependency + exclusions
>
> Hey Emmanuel,
>
> On 5 Jun 2013, at 19:25, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>
>> The Hibernate Search enabled version of TicketMonster relies on
>> Hibernate Search 4.3 which itself has a dependency on Hibernate ORM
>> included in WildFly and JBoss EAP.
>>
>> My first approach was to ask the user to add the Hibernate Search JBoss
>> Module manually into their EAP / WildFly distribution and have it
>> referenced in jboss-deployment-structure.xml.
>> I also had to put Hibernate Search in my POM as provided because the BOM
>> references an older version of Hibernate Search.
>
> We should be targeting the version of HSearch that is in WFK. If the BOM is out of date (highly possible), then please either send a pull to update it or ask Rafael to do so. He or I can do a you a release very quickly once the change is in.
>
>>
>> To avoid the manual step, I tried to list Hibernate Search explicitly in
>> the POM as regular scope and no longer use
>> jboss-deployment-structure.xml. But then I have to play with exclusions
>> which is not too nice either.
>>
>> Which approach is better suited for TicketMonster? And is there a better
>> way?
>
> Fix the HSearch POM so that it marks as optional or provided stuff that you are excluding would be one way. If you don't want to do this, then another option would be to produce a HSearch-for-WF pom as part of HSearch that does it.
>
> In general, it's better to not make the user fiddle with exclusions, and instead do it in the framework itself.
>
>>
>> Here is the commit that moves from a module dependency to plain pom.xml
>> https://github.com/emmanuelbernard/ticket-monster/commit/9da10a15921367d0...
>>
>> Emmanuel
>> _______________________________________________
>> jdf-dev mailing list
>> jdf-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jdf-dev
>
10 years, 10 months
JSON version of Hibernate Search query
by Emmanuel Bernard
Hey everyone,
Sanne and I discussed Hibernate Search queries and serialization in
general. I did play around that to represent Hibernate Search DSL
queries into JSON.
https://gist.github.com/emmanuelbernard/5760676
It is a very first draft (not reviewed). What is really nice is that I did not have to
do much adaptation, the Query DSL is expressive enough to have a one to
one port thanks to its context nature.
I did not work on some of the quirk cases nor tried to optimize the
"80%" use case.
A nice effect is that I manage to unify the FullTextQuery (including the
types filtering), the lucene query part, the faceting definitions and
the faceting selection.
Let me know what you think.
10 years, 10 months
