Re: [hibernate-dev] JPA Events

[Petar Tahchiev]

Hi guys,

any idea how to overcome this? Like I said, when I create my JPA listener
with the following:

@Override
public void onPreUpdateCollection(PreCollectionUpdateEvent event) {
super.touchForUpdate(event.getAffectedOwnerOrNull());
updateCollectionOwner(event);
}


private void updateCollectionOwner(AbstractCollectionEvent event) {
AbstractEntityDefinition aem = (AbstractEntityDefinition)
event.getAffectedOwnerOrNull();

if (aem != null) {
EntityManagerFactory emf =
ApplicationContextProvider.getApplicationContext().getBean("entityManagerFactory",
EntityManagerFactory.class);
EntityManager em =
EntityManagerFactoryUtils.getTransactionalEntityManager(emf);
try {
LOG.debug("Updating lastModifiedDate of: {}", aem.getEntityName());
String hql = "UPDATE " + aem.getEntityName() + " SET " +
LAST_MODIFIED_ATTRIBUTE + " = :attr WHERE id = :id";
Query updateQuery = em.createQuery(hql);
updateQuery.setParameter("attr", aem.getLastModifiedDate());
updateQuery.setParameter("id", aem.getId());
int result = updateQuery.executeUpdate();
LOG.debug(String.valueOf(result));
} catch (Exception ex) {
LOG.error(ex.getMessage(), ex);
}
}
}


Then I get stackoverflow, because when

updateQuery.executeUpdate();

is called, then another PreCollectionUpdateEvent is raised (even though as
you can see in my query I am only updating the LAST_MODIFIED_ATTRIBUTE and
no other field). Is this a bug? Why is PrecollectionUpdateEvent fired when
I am only updating one field of type LocalDateTime?




2018-03-19 20:01 GMT+02:00 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 tha

[hibernate-dev] Problem with releasing 5.1.13.Final

[Gail Badner]

I am able to build the documentation using Andrea's suggestion and now I'm
struggling with gradle.

I released the staging repository on nexus last night to make a deadline.

I also updated the version in build.gradle to 5.1.14-SNAPSHOT, which was
probably a mistake.

Today I went back to build the distributions. The problem is that after
setting the version back to 5.1.13.Final in build.gradle, gradle
automatically recompiles and rebuilds the jars.

That is (obviously) a problem because they won't be the same as what was
uploaded to nexus.

I've been trying some things out on a copy of the directory so I still have
the original jars intact.

I've tried --no-rebuild, but it doesn't seem to work.

Worst case, I suppose I can re-release as 5.1.14.Final on Wednesday, but I
really don't want to do that.

Any suggestions?

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

Re: [hibernate-dev] Cannot build documentation in 5.1 branch

[Gail Badner]

Andrea,

Your suggestion to use  "
https://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd"; worked great.

Thanks!
Gail

On Tue, Mar 20, 2018 at 9:57 AM, Gail Badner  wrote:

> Sorry, I missed that PR somehow. It will get into 5.1.14 for sure.
>
> On Tue, Mar 20, 2018 at 5:27 AM, Sanne Grinovero 
> wrote:
>
>> Hi Gail,
>>
>> I was also hoping this would be included in the next 5.1, it was flagged
>> to get your attention:
>>  - https://github.com/hibernate/hibernate-orm/pull/2151
>>
>> On 20 March 2018 at 11:34, andrea boriero  wrote:
>>
>>> Hi Gail,
>>>
>>> I have tried and I'm facing the same failure what I noticed is that
>>> changing
>>>  http://docbook.org/xml/5.1/dtd/docbook.dtd"; ..>
>>> to >> https://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd"; ..>
>>> seems solving the issue.
>>>
>>>
>>> On 20 March 2018 at 05:16, Gail Badner  wrote:
>>>
>>> > 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 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] Async JDBC proposal

[Mark Rotteveel]

The slides shown are from last year. Somehow that blog still promotes 
that ADBA is somehow a replacement of JDBC, instead of a separate API 
that will exist next to JDBC.

Mark

On 2018-03-20 21:23, Gunnar Morling wrote:
> I don't know whether that's the resource Emmanuel meant to link to,
> but it's the most recent presentation on the topic I'm aware of:
> 
> 
> https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database
> 
> --Gunnar
> 
> 2018-03-20 19:09 GMT+01:00 Mark Rotteveel :
> 
>> Minor nitpick, the proposed asynchronous database API (ADBA) is not
>> part
>> of JDBC, nor does it rely on or use JDBC (or at least
>> implementations
>> doing that wouldn't be truely async).
>> 
>> Mark
>> 
>> PS Could you send the actual link?
>> 
>> On 2018-03-20 12:01, Emmanuel Bernard wrote:
>>> Nothing really new for people at the edge of news but a nice
>>> presentation showing how async JDBC will likely work
>>> 
>> 
> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
>> [1]
>>> 
>>> Emmanuel
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev [2]
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev [2]
> 
> 
> 
> Links:
> --
> [1]
> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
> [2] 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] Async JDBC proposal

[Gunnar Morling]

I don't know whether that's the resource Emmanuel meant to link to, but
it's the most recent presentation on the topic I'm aware of:


https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database

--Gunnar




2018-03-20 19:09 GMT+01:00 Mark Rotteveel :

> Minor nitpick, the proposed asynchronous database API (ADBA) is not part
> of JDBC, nor does it rely on or use JDBC (or at least implementations
> doing that wouldn't be truely async).
>
> Mark
>
> PS Could you send the actual link?
>
> On 2018-03-20 12:01, Emmanuel Bernard wrote:
> > Nothing really new for people at the edge of news but a nice
> > presentation showing how async JDBC will likely work
> > https://docs.google.com/document/d/1jH0znbYwgvGKHC-
> 110zcjRaXLllBsvRKw-pdHrMzRzw
> >
> > Emmanuel
> > ___
> > 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Async JDBC proposal

[Mark Rotteveel]

Minor nitpick, the proposed asynchronous database API (ADBA) is not part 
of JDBC, nor does it rely on or use JDBC (or at least implementations 
doing that wouldn't be truely async).

Mark

PS Could you send the actual link?

On 2018-03-20 12:01, Emmanuel Bernard wrote:
> Nothing really new for people at the edge of news but a nice
> presentation showing how async JDBC will likely work
> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
> 
> Emmanuel
> ___
> 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] [in.relation.to] Only display post summary in list pages

[Guillaume Smet]

On Tue, Mar 20, 2018 at 6:18 PM, Sanne Grinovero 
wrote:

> Maybe you could improve it by forcing a "cut" before images, code snippets
> and such
>

Made the extraction routine more Emmanuel compliant.

There's still this weird post by Vlad on the front page but I prefer to
keep the logic as it is as it makes more sense for all the other posts. And
it's not that shocking.

Just pushed it, we can refine the logic later if there are any more gripes.

Thanks all for taking a look.

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

Re: [hibernate-dev] [in.relation.to] Only display post summary in list pages

[Sanne Grinovero]

Very nice!

This should also mitigate some of the SEO problems.

I see e.g. Emmanuel tends to have long unstructured starts
 - http://staging.in.relation.to/emmanuel-bernard/index.html

Maybe you could improve it by forcing a "cut" before images, code snippets
and such?

Thanks,
Sanne


On 20 March 2018 at 15:02, Guillaume Smet  wrote:

> On Tue, Mar 20, 2018 at 2:23 PM, Yoann Rodiere 
> wrote:
>
> > It's definitely better. There are a few drawbacks, such as the summary
> not
> > displaying for older, non-asciidoctor posts, but the list was barely
> usable
> > without your change, so I think it's still an improvement.
> >
>
> I improved the extraction routine for the older posts. It extracts the very
> first paragraph when it can.
>
>
> > +1 to merge, thanks for working on this!
> >
> > One improvement we could work on is to add an ellipsis when the summary
> is
> > too long, to handle those few posts where there isn't any title. Say we
> > would only keep the first 500 characters, something like that, and add
> > "(...)" at the end if we had to truncate the summary.
> > We may be able to hack something in CSS (I'm not sure, but maybe), but in
> > this case I'd rather try to something in Ruby, if possible. Do you think
> it
> > would be possible?
> >
>
>
> My position on this is that we should take it into account when writing our
> blog posts.
>
> But from now on, if the preamble is longer than 5 paragraphs, I now extract
> the first 3. It fixes the issue with Gunnar's post on the front page.
>
> --
> Guillaume
> ___
> 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] Cannot build documentation in 5.1 branch

[Gail Badner]

Sorry, I missed that PR somehow. It will get into 5.1.14 for sure.

On Tue, Mar 20, 2018 at 5:27 AM, Sanne Grinovero 
wrote:

> Hi Gail,
>
> I was also hoping this would be included in the next 5.1, it was flagged
> to get your attention:
>  - https://github.com/hibernate/hibernate-orm/pull/2151
>
> On 20 March 2018 at 11:34, andrea boriero  wrote:
>
>> Hi Gail,
>>
>> I have tried and I'm facing the same failure what I noticed is that
>> changing
>>  http://docbook.org/xml/5.1/dtd/docbook.dtd"; ..>
>> to > https://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd"; ..>
>> seems solving the issue.
>>
>>
>> On 20 March 2018 at 05:16, Gail Badner  wrote:
>>
>> > 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 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] [in.relation.to] Only display post summary in list pages

[Gunnar Morling]

Great initiative, always wanted to have this! Can you send a PR for
debezium.github.io, too ;)

2018-03-20 16:02 GMT+01:00 Guillaume Smet :

> On Tue, Mar 20, 2018 at 2:23 PM, Yoann Rodiere 
> wrote:
>
> > It's definitely better. There are a few drawbacks, such as the summary
> not
> > displaying for older, non-asciidoctor posts, but the list was barely
> usable
> > without your change, so I think it's still an improvement.
> >
>
> I improved the extraction routine for the older posts. It extracts the very
> first paragraph when it can.
>
>
> > +1 to merge, thanks for working on this!
> >
> > One improvement we could work on is to add an ellipsis when the summary
> is
> > too long, to handle those few posts where there isn't any title. Say we
> > would only keep the first 500 characters, something like that, and add
> > "(...)" at the end if we had to truncate the summary.
> > We may be able to hack something in CSS (I'm not sure, but maybe), but in
> > this case I'd rather try to something in Ruby, if possible. Do you think
> it
> > would be possible?
> >
>
>
> My position on this is that we should take it into account when writing our
> blog posts.
>
> But from now on, if the preamble is longer than 5 paragraphs, I now extract
> the first 3. It fixes the issue with Gunnar's post on the front page.
>
> --
> Guillaume
> ___
> 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] [in.relation.to] Only display post summary in list pages

[Guillaume Smet]

On Tue, Mar 20, 2018 at 2:23 PM, Yoann Rodiere  wrote:

> It's definitely better. There are a few drawbacks, such as the summary not
> displaying for older, non-asciidoctor posts, but the list was barely usable
> without your change, so I think it's still an improvement.
>

I improved the extraction routine for the older posts. It extracts the very
first paragraph when it can.


> +1 to merge, thanks for working on this!
>
> One improvement we could work on is to add an ellipsis when the summary is
> too long, to handle those few posts where there isn't any title. Say we
> would only keep the first 500 characters, something like that, and add
> "(...)" at the end if we had to truncate the summary.
> We may be able to hack something in CSS (I'm not sure, but maybe), but in
> this case I'd rather try to something in Ruby, if possible. Do you think it
> would be possible?
>


My position on this is that we should take it into account when writing our
blog posts.

But from now on, if the preamble is longer than 5 paragraphs, I now extract
the first 3. It fixes the issue with Gunnar's post on the front page.

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

Re: [hibernate-dev] [in.relation.to] Only display post summary in list pages

[Yoann Rodiere]

It's definitely better. There are a few drawbacks, such as the summary not
displaying for older, non-asciidoctor posts, but the list was barely usable
without your change, so I think it's still an improvement.
+1 to merge, thanks for working on this!

One improvement we could work on is to add an ellipsis when the summary is
too long, to handle those few posts where there isn't any title. Say we
would only keep the first 500 characters, something like that, and add
"(...)" at the end if we had to truncate the summary.
We may be able to hack something in CSS (I'm not sure, but maybe), but in
this case I'd rather try to something in Ruby, if possible. Do you think it
would be possible?

On Tue, 20 Mar 2018 at 14:02 Guillaume Smet 
wrote:

> Hi,
>
> It's been bugging me for a while and I took some time this morning to do
> some changes to the post list pages of the blog.
>
> We currently display the whole articles whereas I thought it would be
> better to only display a summary of them and get people to the full article
> with a button.
>
> I pushed the changes on http://staging.in.relation.to/ .
>
> It's based on the Asciidoctor preamble (most of the time) so it takes the
> paragraphs that are before the first title. It's not perfect but it works
> pretty well for most of the posts. We should probably try to write our
> posts so that the summary looks good.
>
> Thoughts?
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
-- 
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] [in.relation.to] Only display post summary in list pages

[Guillaume Smet]

Hi,

It's been bugging me for a while and I took some time this morning to do
some changes to the post list pages of the blog.

We currently display the whole articles whereas I thought it would be
better to only display a summary of them and get people to the full article
with a button.

I pushed the changes on http://staging.in.relation.to/ .

It's based on the Asciidoctor preamble (most of the time) so it takes the
paragraphs that are before the first title. It's not perfect but it works
pretty well for most of the posts. We should probably try to write our
posts so that the summary looks good.

Thoughts?

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

Re: [hibernate-dev] Cannot build documentation in 5.1 branch

[Sanne Grinovero]

Hi Gail,

I was also hoping this would be included in the next 5.1, it was flagged to
get your attention:
 - https://github.com/hibernate/hibernate-orm/pull/2151

On 20 March 2018 at 11:34, andrea boriero  wrote:

> Hi Gail,
>
> I have tried and I'm facing the same failure what I noticed is that
> changing
>  http://docbook.org/xml/5.1/dtd/docbook.dtd"; ..>
> to  https://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd"; ..>
> seems solving the issue.
>
>
> On 20 March 2018 at 05:16, Gail Badner  wrote:
>
> > 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 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] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

[Guillaume Smet]

On Tue, Mar 20, 2018 at 1:06 PM, Gunnar Morling 
wrote:

> This is a spec-level API, defined in ValidatorContext:
>
> https://github.com/beanvalidation/beanvalidation-
> api/blob/master/src/main/java/javax/validation/ValidatorContext.java#L77
>
> So unless we change the rules (there might be some leeway now when
> formalizing compat rules for Jakarta EE), we cannot really deprecate this
> feature.
>

Raaah, totally missed it at a quick glance as it's overridden in
HibernateValidatorContext for chaining.

@Emmanuel unfortunately we would still need to keep the Executable handy in
case the parameter name provider is overridden at some point. The idea was
to completely get rid of it.

Maybe we could have some gain by avoiding the parameter name generation in
most cases but I'm not sure it's worth making the code less readable.

Let's forget about it.

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

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

[Gunnar Morling]

This is a spec-level API, defined in ValidatorContext:


https://github.com/beanvalidation/beanvalidation-api/blob/master/src/main/java/javax/validation/ValidatorContext.java#L77

So unless we change the rules (there might be some leeway now when
formalizing compat rules for Jakarta EE), we cannot really deprecate this
feature.

2018-03-19 17:47 GMT+01:00 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Cannot build documentation in 5.1 branch

[andrea boriero]

Hi Gail,

I have tried and I'm facing the same failure what I noticed is that changing
 http://docbook.org/xml/5.1/dtd/docbook.dtd"; ..>
to https://www.oasis-open.org/docbook/xml/5.0b5/dtd/docbook.dtd"; ..>
seems solving the issue.


On 20 March 2018 at 05:16, Gail Badner  wrote:

> 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 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

[Sanne Grinovero]

On 20 March 2018 at 10:50, Emmanuel Bernard  wrote:

> I think treating the client side HSearch input and transparently push it
> down is a recipe for disaster. Looks cool on paper until you have
> divergence between HSearch proper and Infinispan's or whatever
> Infinispan exposes.
>

​Looks like we agree on the premise, but you didn't comment on the
proposal?​

Thanks



>
> So yes we could have GridDialect specific metadata information around
> indexing but I would not reuse Hibernate Search annotations for that.
> Treat Infinispan like any of the other GridDialect providers.
>
> As for the way to express FTQ, then Infinispan needs to make Ickle more
> powerful.
>
> Emmanuel
>
>
> On Wed 18-03-14 11:52, 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] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

[Sanne Grinovero]

Let's hypotethically assume that some scenario needs this. I'm thinking of
an application which as different compilation units, so some module might
have been compiled with different conventions and need different name
resolvers.

Would you enforce such a use case to use different, independently
configured ValidatorContext instances? Would that be viable && practical?



On 19 March 2018 at 16:47, Guillaume Smet  wrote:

> 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Async JDBC proposal

[Radim Vansa]

Emmanuel, is this a correct link? That one is ORM 5.1 vs. 5.3 binary 
compatibility analysis...

I have seen [1] posted earlier today on; is this what you have in mind?

I am very happy that JDBC will have an async variant; we have some plans 
for asynchronous persistence in Infinispan so this might would be 
definitely useful to our JDBC stores. I only wish there'd be an async 
thread-independent JTA next, too.

Radim

[1] 
https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database

On 03/20/2018 12:01 PM, Emmanuel Bernard wrote:
> Nothing really new for people at the edge of news but a nice
> presentation showing how async JDBC will likely work
> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
>
> Emmanuel
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa 
JBoss Performance Team

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

[hibernate-dev] Async JDBC proposal

[Emmanuel Bernard]

Nothing really new for people at the edge of news but a nice
presentation showing how async JDBC will likely work
https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw

Emmanuel
___
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

[Emmanuel Bernard]

I think treating the client side HSearch input and transparently push it
down is a recipe for disaster. Looks cool on paper until you have
divergence between HSearch proper and Infinispan's or whatever
Infinispan exposes.

So yes we could have GridDialect specific metadata information around
indexing but I would not reuse Hibernate Search annotations for that.
Treat Infinispan like any of the other GridDialect providers.

As for the way to express FTQ, then Infinispan needs to make Ickle more
powerful.

Emmanuel

On Wed 18-03-14 11:52, 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] [HV] Retiring HibernateValidatorContext#parameterNameProvider()

[Emmanuel Bernard]

Can't you a priori apply your optimization and have a if ( perInstance
!= perFactory ) backdoor? Meaning I don't really get why you cannot
apply your optimization by default and fall back to a slow codepath when
the value is overridden.

Emmanuel

On Mon 18-03-19 17:47, Guillaume Smet wrote:
>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
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [HSEARCH][V6-POC] FieldBridge 2.0

[Yoann Rodiere]

If you want to have a look at the sources on Github directly, and don't
want to clone the repo to have a look in your IDE, here is the paragraph
listing the bridge implementations, but with links to Github sources:

   - ISBNBridge
   

is
   a ValueBridge. Hibernate Search is able to detect from its class metadata
   that it can only be applied to ISBN values, and generates a String field.
   The bridge is applied using a @Field
   

   annotation on Book#isbn
   

   .
   You can find an equivalent use of the bridge in the programmatic mapping
   in ProgrammaticMappingContributor
   

   .
   - Another value bridge is applied to Library#services
   

   and is implicitly applied to every value of the list.
   - MultiKeywordStringBridge
   

is
   a PropertyBridge which turns a comma-separated string into multiple field
   values. It is admittedly a very simple PropertyBridge, but it has the
   advantage of showing pretty clearly how a custom bridge is declared and
   implemented.
   The bridge is applied using its custom @MultiKeywordStringBridge
   

   annotation on Document#tags
   

   .
   You can find an equivalent use of the bridge in the programmatic mapping
   in ProgrammaticMappingContributor: look for the line where
   "MultiKeywordStringBridge.Builder" is used
   

   .
   - GeoPointBridge
   

is
   a more representative example of what an advanced bridge could be. It's a
   built-in bridge, but it could definitely be implemented by a third-party:
   no internal APIs are used in its implementation. Note that one
   characteristic of this field is that it can be used both as a TypeBridge or
   as a PropertyBridge, just as the @Spatial annotation in Search 5.
   The bridge is applied using its dedicated @GeoPointBridge
   

   annotation to type Library
   
,
   with @Latitude
   

   and @Longitude
   

[hibernate-dev] [HSEARCH][V6-POC] FieldBridge 2.0

[Yoann Rodiere]

Hello,

In Search 6, we are changing the field bridge APIs to move away from Lucene
dependencies. Similarly to the query DSL, this breaks backward
compatibility whatever we do, so we had a look to improving the field
bridge API a bit with some other changes.

The result is we have three types of bridges:

   - *ValueBridges* can be applied to values, i.e. either a property value
   directly, or container values extracted from the property (list elements,
   map keys, ...). They cannot be parameterized and cannot have dedicated
   annotations (at least for now), and they are applied to a mapping using
   @Field(valueBridge = ...). They are supposed to be applied to simple types
   (LocalDate, some Enum, some immutable user type, ...) and perform a 1-1
   mapping between the value and a *single* index field. Implementations
   are supposed to work as bidirectional functions: one method transforms the
   POJO-side type into the Index-side type, and one method does the opposite.
   - *TypeBridges* can be applied to types, can be parameterized, they each
   have a dedicated annotation (@MyCustomTypeBridge for instance). Their
   implementations are supposed to use specific APIs to access both the
   property values and the index fields, so that Hibernate Search is aware of
   the necessary input data (useful for dirty checking) and of the index
   fields created by the bridge, along with their characteristics (field type,
   stored or not, analyzer, ...).
   - *PropertyBridges* can be applied to properties, can be
   parameterized, they each have a dedicated annotation
   (@MyCustomPropertyBridge for instance). Their implementations are supposed
   to use specific APIs to access both the property values and the index
   fields, so that Hibernate Search is aware of the necessary input data
   (useful for dirty checking) and of the index fields created by the bridge,
   along with their characteristics (field type, stored or not, analyzer, ...).

The expectation is that most users will only need to implement ValueBridge,
which is the simpler one. Users with more advanced needs will be able to
implement TypeBridge/PropertyBridge, which are more complex but are also
much more powerful.

Some aspects of the bridge API are still in the works, so don't be alarmed
to not see them:

   - Access to the type/property data in TypeBridge and PropertyBridge is
   still a bit rough, missing in particular support for container types (List,
   Map, ...).
   - During projections, transforming the projected data using bridges is
   not supported yet.

The showcase contains a few simple bridge implementations.

   - org.hibernate.search.v6poc.integrationtest.showcase.library.bridge.
   *ISBNBridge* is a ValueBridge. Hibernate Search is able to detect from
   its class metadata that it can only be applied to ISBN values, and
   generates a String field.
   The bridge is applied using a @Field annotation
   on 
org.hibernate.search.v6poc.integrationtest.showcase.library.model.Book#isbn.
   You can find an equivalent use of the bridge in the programmatic mapping
   in 
org.hibernate.search.v6poc.integrationtest.showcase.library.model.ProgrammaticMappingContributor.
   - Another value bridge is applied
   to 
org.hibernate.search.v6poc.integrationtest.showcase.library.model.Library#services
   and is implicitly applied to every value of the list.
   - org.hibernate.search.v6poc.integrationtest.showcase.library.bridge.
   *MultiKeywordStringBridge* is a PropertyBridge which turns a
   comma-separated string into multiple field values. It is admittedly a very
   simple PropertyBridge, but it has the advantage of showing pretty clearly
   how a custom bridge is declared and implemented.
   The bridge is applied using its custom "@MultiKeywordStringBridge"
   annotation
   on 
org.hibernate.search.v6poc.integrationtest.showcase.library.model.Document#tags.
   You can find an equivalent use of the bridge in the programmatic mapping
   in
   
org.hibernate.search.v6poc.integrationtest.showcase.library.model.ProgrammaticMappingContributor:
   look for the line where "MultiKeywordStringBridge.Builder" is used.
   - org.hibernate.search.v6poc.entity.pojo.bridge.builtin.spatial.
   *GeoPointBridge* is a more representative example of what an advanced
   bridge could be. It's a built-in bridge, but it could definitely be
   implemented by a third-party: no internal APIs are used in its
   implementation. Note that one characteristic of this field is that it can
   be used both as a TypeBridge or as a PropertyBridge, just as the @Spatial
   annotation in Search 5.
   The bridge is applied using its dedicated "@GeoPointBridge" annotation
   to
   type 
org.hibernate.search.v6poc.integrationtest.showcase.library.model.Library,
   with "@Latitude" and "@Longitude" annotations on the relevant properties of
   this type.
   You can find an equivalent use of the bridge in the programmatic mapping
   in
   
org.hibernate.search.v6poc.integrationtest.sho