[hibernate-dev] Cannot build documentation in 5.1 branch

[Gail Badner]

I'm in the process of releasing 5.1.13, and I'm not able to build Hibernate
Integrations Guide. I was able to build it for 5.1.12 without any problem.

The task that fails is assembleDocumentation and is the error is below. [1]

There have not been any changes to that guide for 5.1.13, so I'm not sure
why this would be failing.

I even tried executing the same task using 5.1.12 source, and it fails with
the same error.

I need to tag the release tonight. I'll have to get this resolved somehow
tomorrow so I can build the distributions for the release.

Does anyone know how to fix this?

Thanks,
Gail

[1]
rendering Book(integrationsGuide) en-US/html
Extending script classloader with the jdocbookXsl dependencies
redirecting console output to file
[/home/gbadner/git/hibernate-orm-5.1.13/documentation/target/docbook/work/integrationsGuide/log/console-en-US-html.log]
Error on line 1 column 1 of http://docbook.org/xml/5.0/dtd/docbook.dtd:
  Error reported by XML parser: The markup declarations contained or
pointed to by the document type declaration must be well-formed.
Resetting console output
:documentation:renderDocBook_integrationsGuide_en-US_html FAILED
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Cache testing & JCache

[Steve Ebersole]

The initial hibernate-jcache code would create JCache Cache instance "on
the fly" as they were needed if not already defined.  As part of a
discussion about JCache support, it was agreed that this should not happen.

To be clear... the integration code
calls javax.cache.CacheManager#getCache(java.lang.String).  If we are
returned nothing, its a choice between throwing an exception or
calling javax.cache.CacheManager#createCache.  The consensus among the
cache providers was that an exception should be thrown as the standard
outcome.

However, in testing I wonder if we want to allow that "on the fly" creation
to happen.  Opinions?  And if not, thoughts on how to best pre-define all
the needed Cache instances?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote

[Fabio Massimo Ercoli]

Hi Sanne,

what you speak of in my opinion is a very very cool feature.
Moreover server-side indexes (and remote dialect) are more suitable for
Openshift applications.

Using standard javax.persistence.Index APIs could be a very nice
alternative to avoid confusion with Hibernate Search client side usage.
For the problem (B) maybe we can extend the API (adding a some non standard
annotation, at least one for the analyze).

I'm really interested in this development. Thank you.

Fabio


On Wed, Mar 14, 2018 at 12:52 PM, Sanne Grinovero 
wrote:

> Hi all,
>
> this one is a very desirable feature, yet tricky as there's high
> chances of ambiguity and confusion for end users.
>
>
> # Infinispan Remote indexing
>
> Infinispan embeds the Hibernate Search engine, and uses it to index
> data being inserted in any cache having indexing enabled. As you know
> Infinispan can be used to store Java POJOs, which get serialized using
> JBoss Marshalling - or encoded into Protobuf entries using Infinispan
> Protostream as helper layer.
>
> Hibernate OGM supports both modes, one meant for "Infinispan Embedded"
> and one for "Infinispan Remote" as that's what each encoding strategy
> is suited for.
>
>
> # Protobuf & indexing
>
> Protobuf is a well defined format with plenty of documentation which
> focuses on a "schema" of the encoding; Hibernate OGM is able to
> generate such schemas dynamically and will generate encoders and
> decoders which follow the encoding guidelines for Java objects.
>
> The meta schema of protobuf is not super flexible, yet there's the
> option of annotating the Protobuf schema elements using "annotations"
> in comments.
> Protostream allows inserting Hibernate Search annotations directly in
> these comments and will use them to generate the server side indexing
> configuration, implicitly also allowing such properties to be queried
> using indexed.
>
> For example you might have this string literally within the comments:
>  "@Field(store = Store.YES, analyze = Analyze.YES)"
>
> A full example of schema can be found here [1].
> (The Infinispan documentation is a bit sparse on this as they
> encourage people to use another code gen tool, best refer to tests as
> examples when working for OGM)
>
>
> # What should OGM users experience?
>
> A naive solution would be to allow people to use the Hibernate Search
> annotations on their JPA entities, and we have OGM copy these into the
> generated schema; there's a number of problems with that:
>  - not all such annotations "translate" equally well [2]
>  - there's a mismatch between JPA properties and underlying encoding fields
>  - if I run a FullTextQuery do I expect it to work remotely?
>  - what if I want to use Hibernate Search locally as well or instead?
>  - references to local classes obviously won't work (custom
> fieldbridges, analyzers, etc..)
>
> An alternative is to look at these as "indexes" of the underlying
> store, so we'd use them to hint the Infinispan server about user
> provided hints such as those generated by `javax.persistence.Index`.
> I do think this is the cleaner approach, yet has two drawbacks:
>  A- I guess ORM might implicitly generate some indexes in its metadata
> which the user might not have explicitly asked; e.g. accelerate unique
> constraints and foreign keys; it's possible these might not be as
> useful as expected in the Infinispan case.
>  B- we won't be able to leverage the awesome full-text capabilities :-(
>
> I believe A is something we could ignore for now and revisit if
> there's actual demand.
>
> B is also not urgent, yet disappointing limitation as this capability
> is a distinguishing feature of this NoSQL. Would we agree that
> exposing such full-text capabilities would best be let to an ad-hoc
> backend in Hibernate Search 6?
>
>
> Thanks,
> Sanne
>
> 1 - http://blog.infinispan.org/2018/02/restful-queries-
> coming-to-infinispan-92.html
> 2 - https://github.com/infinispan/infinispan/blob/master/remote-
> query/remote-query-server/src/main/java/org/infinispan/
> query/remote/impl/indexing/IndexingMetadataCreator.java#L31
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JPA Events

[Petar Tahchiev]

Hi Steve,

thank you for your reply. I really appreciate it. Here's my situation: my
client asked me to get the dirty Products. Now the Product has a
List manufacturers so to me it is obvious that when the
manufacturers are changed then the Product is dirty, and this is exactly
what I try to achieve.
Unfortunately I can't do this - neither with JPA, nor with Hibernate
directly.

- JPA has only @PreUpdate and @PrePersist which are not invoked if the
List manufacturers are changed.

- Hibernate however has several more listeners
(PreCollectionUpdateEventListener, PreCollectionRemoveEventListener,
PreCollectionRecreateEventListener). So I created my own EventListeners and
implement those interfaces. Now when the Collection is modified, I
set the Product.isDirty flag to TRUE and try to save the Product.
Unfortunately the moment I do that then another PreCollectionUpdate is
fired so I get a StackOverflow error. I was thinking to update the product
directly with JDBC and bypass Hibernate, but unfortunately my client has
requested the solution to be database agnostic and so using plain JDBC will
bring me a lot of troubles.

I can, however, implement my requirements with EclipseLink, as noted in
this comment:

https://github.com/javaee/jpa-spec/issues/167#issuecomment-374254412

But I really like Hibernate and I don't want to migrate all my code to
EclipseLink :(

What does the rest of the Hibernate team think? I know it's a matter of
interpretation of the spec, but is it really going to be a big change if
PreUpdate events were fired when a List or a Map
attributes are changed?


2018-03-19 17:32 GMT+02:00 Steve Ebersole :

> It is actually very unclear.  Look at the wording... "...update
> operations to *entity* data...".  So clearly it boils down to your
> definition of "entity data" and what is being updated, as Oliver mentions
> as well.  We take the interpretation that since we are not updating the
> entity table here, we do not fire the event (unless the entity is
> versioned, in which case the change in the collection would cause a version
> increment and the entity table to be updated as well).
>
> In Hibernate, this would translate to a collection event - but of course
> JPA has no such notion.  And the distinction is actually quite important
> for supporting things like Envers, so it would need to be a VERY compelling
> reason to change this behavior in Hibernate.
>
> On Mon, Mar 19, 2018 at 9:55 AM Petar Tahchiev 
> wrote:
>
>> Hi guys,
>>
>> I opened an issue in the JPA spec here yesterday:
>>
>> https://github.com/javaee/jpa-spec/issues/167
>>
>> because @PreUpdate and @PrePersist events are not fired when I save a
>> collection on the owner. Since then, a discussion with Oliver Gierke from
>> the SpringDATA team started and I wanted to know your opinion on this.
>>
>> Basically the question is: if you have Product with a Collection
>> attribute and you update the collection, shall @PreUpdate event be fired.
>>
>> As Oliver mentioned the JPA spec says:
>> ---
>> The PreUpdate and PostUpdate callbacks occur before and after the database
>> update operations to entity data respectively.
>> ---
>>
>> so to me it is obvious that when an attribute of the Product is changed
>> then this means that @PreUpdate event for the Product must be fired.
>>
>> What do you think? Should I open a bug in Hibernate?
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>


-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [HSEARCH][V6-POC] Syntax for query building

[Yoann Rodiere]

Hello,

In Search 6, we are changing the Query DSL APIs to move away from Lucene
dependencies. Since this breaks backward compatibility whatever we do, we
had a look to improve the the syntax a little bit with some other changes.

In particular, for query predicate building, we experimented with three
syntaxes when it comes to nesting:

   - a fully-fluid syntax, allowing nested predicate definition through
   chained calls (and potentially an ".end()" call where necessary to get back
   to the parent predicate).
   - a lambda-based syntax, allowing nested predicate definition by passing
   lambdas that create the nested predicate.
   - an "object-based" syntax, allowing to create an object representing
   your predicate, and then pass it as an argument to another predicate to
   nest it. This is pretty similar to the QueryBuilder syntax in Search 5.

In the showcase module of the proof-of-concept (
https://github.com/hibernate/hibernate-search-6-poc/tree/master/integrationtest/showcase/library),
I included multiple implementations of the DAOs to demonstrate various
syntaxes. Since the fully-fluid syntax does not allow to handle conditions
or loops within a single chained call, some of the implementations actually
mix multiple syntaxes:

   - Package
   org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.object
   demonstrates pure "object-based" syntax
   - Package 
org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.lambda
   demonstrates pure "lambda-based" syntax
   - Package 
org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.fluidandlambda
   demonstrates fluid syntax resorting to lambda-based syntax when conditions
   or loops are necessary.
   - Package 
org.hibernate.search.v6poc.integrationtest.showcase.library.dao.syntax.fluidandobject
   demonstrates fluid syntax resorting to object-based syntax when conditions
   or loops are necessary.

My questions:

   - Do all of these query building syntaxes make sense to you?
   - Do you think we need all of them?
   - Is one better than the others?

Some elements of thought:

   - There may not be a "one-size-fits-all" solution; I personally like the
   "fluid" syntax best for "shallow" queries with little to no nesting, and
   the "fluid+lambda" syntax best for deeply nested queries. To make your own
   opinion, you can have a look at implementations of
   "DocumentDao#searchAroundMe" for a query with complex nesting, and at
   implementations of "LibraryDao#search" for a "shallow" query.
   - Purely lambda or purely object syntax, in my opinion, are more
   verbose. The syntax feels more "to the point" where we can use chained
   calls (fluid syntax).
   - The fluid syntax is not very IDE-friendly when nesting predicates, as
   code formatting will ignore the implicit structure of chained calls (it
   will remove indents that previously made nesting obvious).
   - With lambdas being regularly advised against for various reasons, we
   might want to offer at least one other way of doing things.

-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [HSEARCH][V6-POC] RFC on the Hibernate Search 6 APIs

[Yoann Rodiere]

Hello,

It's been some time we have been working on a proof-of-concept for Search
6, and I think it is mature enough to receive some early feedback. So to
anyone interested: I would love to read your comments! Note that the APIs
are not set in stone yet, everything could still change depending on the
feedback.

To help you form an opinion, I added a "showcase" module with a relatively
realistic domain model (that of Libraries and their Books), a Hibernate
Search mapping and some queries. The showcase uses the Elasticsearch
backend, which is (for now) the only one available; Guillaume is working on
the Lucene one.
The proof-of-concept is available here:
https://github.com/hibernate/hibernate-search-6-poc and the showcase is
located in the "integrationtest/showcase/library" directory.

You can find:

   - the domain model, mapped using annotations,
   in org.hibernate.search.v6poc.integrationtest.showcase.library.model
   - the data access objects implementing CRUD operations
   in org.hibernate.search.v6poc.integrationtest.showcase.library.dao; there
   are various implementations of the same DAO contracts (more on this in
   another email thread).
   - the custom bridge implementations
   in org.hibernate.search.v6poc.integrationtest.showcase.library.bridge (more
   on this in another email thread)

A test allowing you to see it all in action is available in
src/test/java/org/hibernate/search/v6poc/integrationtest/showcase/OrmElasticsearchLibraryShowcaseIT.java
. You can launch it:

   - from the command line with "mvn clean install -DskipTests; mvn clean
   verify -pl integrationtest/showcase/library" (an Elasticsearch instance
   will be spawned automatically)
   - or more interstingly from your IDE, with breakpoints. You will need an
   Elasticsearch cluster running and accessible from localhost:9200.

I will be starting separate email threads for some topics I would
especially like feedback on. If there are some other topics you would like
discussed, feel free to answer here or start another thread.

As a reminder, and as an explanation of why so many things changed, here
are the main goals of Hibernate Search 6:

   - Overhaul the APIs to remove the dependency to Lucene, so that other
   technologies can be integrated without hacks (Elasticsearch in particular,
   but also maybe in the future Solr).
   - Overhaul the bridge APIs to allow:
  - Better integration with other technologies (such as Elasticsearch),
  in particular by abstracting access to indexed documents (HSEARCH-2186
  )
  - Detection by Hibernate Search of the properties being used, for
  better dirty checking [not yet implemented, but the APIs should
allow that]
  (HSEARCH-2496 )
   - Overhaul the Query API to:
  - offer a less verbose syntax for simpler queries
  - return typed results: if you query the Book index, you get a
  List, not a raw List (HSEARCH-2225
  )
  - be generic, yet extensible depending on the integration (e.g. allow
  to nest Elasticsearch JSON inside a query predicate) (HSEARCH-2498
  )
   - Generally ensure the architecture:
  - will allow detection by Hibernate Search of the load graph to use
  when fetching entities from Hibernate ORM for mass indexing.
  - will make it easier to implement alternative mappers in the future (
  HSEARCH-1800 ,
  HSEARCH-1401 ).

While we were at it, I gave a shot to some additional features I felt could
be useful:

   - User-defined bridge annotations for user-defined bridges (HSEARCH-175
   )
   - Give access to more application context in the bridges (HSEARCH-1839
   )
   - Comply with the JPA access type when accessing entity properties (
   HSEARCH-383 )

-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

[Guillaume Smet]

Hi,

So I know we like to have API compatibility discussions these days, so
let's start a new one.

FWIW, this discussions doesn't come out of the blue, it's based on
discussions we had for one of Marko's PRs.

In HV, you can set the parameter name provider at the VF level and you can
also override it on a per Validator basis using
HibernateValidatorContext#parameterNameProvider().

To be honest, I'm a bit skeptical about the usefulness of overriding this
setting at the Validator level: it really seems to be a global setting,
especially because it has an influence on what could be considered a
metadata and metadata are considered static in HV.

At the moment, the parameter name is resolved at runtime each time it's
required due to this feature.

I would like to deprecate the feature for now and possibly remove it in a
future version (I thought about maybe keeping the method for a while but
logging a warning stating it's not doing anything anymore?).

We expect some runtime performance enhancement (this is not the reason of
this post) but it seems we could also get rid of storing the Executable in
the metadata and reduce our memory footprint for executables, which would
be nice.

Thoughts?

-- 
Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JPA Events

[Steve Ebersole]

It is actually very unclear.  Look at the wording... "...update operations
to *entity* data...".  So clearly it boils down to your definition of
"entity data" and what is being updated, as Oliver mentions as well.  We
take the interpretation that since we are not updating the entity table
here, we do not fire the event (unless the entity is versioned, in which
case the change in the collection would cause a version increment and the
entity table to be updated as well).

In Hibernate, this would translate to a collection event - but of course
JPA has no such notion.  And the distinction is actually quite important
for supporting things like Envers, so it would need to be a VERY compelling
reason to change this behavior in Hibernate.

On Mon, Mar 19, 2018 at 9:55 AM Petar Tahchiev 
wrote:

> Hi guys,
>
> I opened an issue in the JPA spec here yesterday:
>
> https://github.com/javaee/jpa-spec/issues/167
>
> because @PreUpdate and @PrePersist events are not fired when I save a
> collection on the owner. Since then, a discussion with Oliver Gierke from
> the SpringDATA team started and I wanted to know your opinion on this.
>
> Basically the question is: if you have Product with a Collection
> attribute and you update the collection, shall @PreUpdate event be fired.
>
> As Oliver mentioned the JPA spec says:
> ---
> The PreUpdate and PostUpdate callbacks occur before and after the database
> update operations to entity data respectively.
> ---
>
> so to me it is obvious that when an attribute of the Product is changed
> then this means that @PreUpdate event for the Product must be fired.
>
> What do you think? Should I open a bug in Hibernate?
>
> --
> Regards, Petar!
> Karlovo, Bulgaria.
> ---
> Public PGP Key at:
> http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] JPA Events

[Petar Tahchiev]

Hi guys,

I opened an issue in the JPA spec here yesterday:

https://github.com/javaee/jpa-spec/issues/167

because @PreUpdate and @PrePersist events are not fired when I save a
collection on the owner. Since then, a discussion with Oliver Gierke from
the SpringDATA team started and I wanted to know your opinion on this.

Basically the question is: if you have Product with a Collection
attribute and you update the collection, shall @PreUpdate event be fired.

As Oliver mentioned the JPA spec says:
---
The PreUpdate and PostUpdate callbacks occur before and after the database
update operations to entity data respectively.
---

so to me it is obvious that when an attribute of the Product is changed
then this means that @PreUpdate event for the Product must be fired.

What do you think? Should I open a bug in Hibernate?

-- 
Regards, Petar!
Karlovo, Bulgaria.
---
Public PGP Key at:
http://pgp.mit.edu:11371/pks/lookup?op=get=0x19658550C3110611
Key Fingerprint: A369 A7EE 61BC 93A3 CDFF  55A5 1965 8550 C311 0611
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev