Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

[Gail Badner]

I'm happy to see all the progress on this while I've been occupied with
5.1.13 and some other urgent issues.

I hope to have time to get caught up on things later today or tomorrow.

On Thu, Mar 22, 2018 at 10:55 AM, Gunnar Morling 
wrote:

> I've mostly used Japicmp recently http://siom79.github.io/japicmp/). Works
> pretty well, but it lacks a way to distinguish between API and SPI, so
> you'll likely also see "false positives". In fact I thought it's the one
> you'd be using, but it doesn't seem so from looking at the report attached
> to that wiki page.
>
> 2018-03-22 16:59 GMT+01:00 Sanne Grinovero :
>
> > On 22 March 2018 at 15:55, David Lloyd  wrote:
> > > This tool is usually pretty good; in fact I think it likely that it's
> > > the best of its kind.  The false positives are really a fairly recent
> > > development AFAIK; I don't recall hitting any when I ran it for our
> > > EJB changes a year or two ago.  It might be a good idea to contribute
> > > a fix for the problem upstream; it might even be relatively easy to
> > > do.  Or it could already be fixed.
> >
> > Good to know, thanks. I might explore that next week.
> >
> > Sanne
> >
> > >
> > > On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole 
> > wrote:
> > >> Not sure.  animal-sniffer is the other one I know, but not sure it
> > would be
> > >> better.
> > >>
> > >> On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero  >
> > >> wrote:
> > >>>
> > >>> To make sure all the noise form "false positives" won't get us to
> miss
> > >>> something, someone knows an alternative tool which can do better?
> > >>>
> > >>> Thanks,
> > >>> Sanne
> > >>>
> > >>>
> > >>> On 22 March 2018 at 14:22, Steve Ebersole 
> wrote:
> > >>> > Yes there were "lots of differences" but a vast majority of them
> are
> > >>> > false-positives, not just those listed in the already massive
> "false
> > >>> > positives" section.  I've been going through the non-"false
> positive"
> > >>> > section and "resolving" specific items (via strike-through) with
> > either
> > >>> > (1)
> > >>> > link to Jira fixing it or (2) comment as to the reason I believe it
> > is a
> > >>> > false-positive.
> > >>> >
> > >>> > I did not bother striking through the "false positives" section.
> > >>> >
> > >>> > At this point there are very few unresolved items in this list.
> > Those
> > >>> > items
> > >>> > require more discussion
> > >>> >
> > >>> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero <
> sa...@hibernate.org
> > >
> > >>> > wrote:
> > >>> >>
> > >>> >> Thanks Gail, great job!
> > >>> >> I fixed a trivial one, just a thousand to go ;)
> > >>> >>
> > >>> >> On 16 March 2018 at 23:09, Gail Badner 
> wrote:
> > >>> >> > I've moved the document to
> > >>> >> >
> > >>> >> >
> > >>> >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC-
> > 110zcjRaXLllBsvRKw-pdHrMzRzw
> > >>> >> > .
> > >>> >> >
> > >>> >> > Please let me know if you need an invite to view the document.
> > >>> >> >
> > >>> >> > The attachments are still at  https://developer.jboss.org/wiki/
> > >>> >> > HibernateORMBinaryCompatibilityBetween51And53.
> > >>> >> >
> > >>> >> > Regards,
> > >>> >> > Gail
> > >>> >> >
> > >>> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner <
> gbad...@redhat.com
> > >
> > >>> >> > wrote:
> > >>> >> >
> > >>> >> >> Hi,
> > >>> >> >>
> > >>> >> >> There were lots of differences in the compatibility report, so
> > as a
> > >>> >> >> first
> > >>> >> >> step, I've excluded packages/classes that I considered SPI,
> > >>> >> >> internal,
> > >>> >> >> or
> > >>> >> >> "grey area". This reduced the the differences to a more
> > manageable
> > >>> >> >> amount.
> > >>> >> >>
> > >>> >> >> You can see a summary of the incompatibilities along with
> > suggested
> > >>> >> >> mitigation at [1].
> > >>> >> >>
> > >>> >> >> The report is attached to [1], along with a zip with
> instructions
> > >>> >> >> for
> > >>> >> >> running the report.
> > >>> >> >>
> > >>> >> >> I believe there are some "false positives" in the report, and I
> > have
> > >>> >> >> documented them in the section, "False Positives?".
> > >>> >> >>
> > >>> >> >> Feel free to comment on the article.
> > >>> >> >>
> > >>> >> >> Thanks,
> > >>> >> >> Gail
> > >>> >> >>
> > >>> >> >> [1] https://developer.jboss.org/wiki/
> > HibernateORMBinaryCompatibilit
> > >>> >> >> yBetween51And53
> > >>> >> >>
> > >>> >> >>
> > >>> >> > ___
> > >>> >> > 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
> > >
> > >
> > >
> > > --
> > > - DML
> > 

Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

[Guillaume Smet]

On Thu, Mar 22, 2018 at 4:20 PM, Sanne Grinovero 
wrote:

> To make sure all the noise form "false positives" won't get us to miss
> something, someone knows an alternative tool which can do better?
>

We use this one for HV https://github.com/siom79/japicmp . Not sure it's
better though.

If not, I'd say the best way to rule out the false positives would be to
open issues on the projects and get the fixes integrated there.

Of course, it will require some additional effort from us.

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

Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

[Steve Ebersole]

I just pushed the first round of fixes for this upstream.

On Thu, Mar 22, 2018 at 11:00 AM Sanne Grinovero 
wrote:

> On 22 March 2018 at 15:55, David Lloyd  wrote:
> > This tool is usually pretty good; in fact I think it likely that it's
> > the best of its kind.  The false positives are really a fairly recent
> > development AFAIK; I don't recall hitting any when I ran it for our
> > EJB changes a year or two ago.  It might be a good idea to contribute
> > a fix for the problem upstream; it might even be relatively easy to
> > do.  Or it could already be fixed.
>
> Good to know, thanks. I might explore that next week.
>
> Sanne
>
> >
> > On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole 
> wrote:
> >> Not sure.  animal-sniffer is the other one I know, but not sure it
> would be
> >> better.
> >>
> >> On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero 
> >> wrote:
> >>>
> >>> To make sure all the noise form "false positives" won't get us to miss
> >>> something, someone knows an alternative tool which can do better?
> >>>
> >>> Thanks,
> >>> Sanne
> >>>
> >>>
> >>> On 22 March 2018 at 14:22, Steve Ebersole  wrote:
> >>> > Yes there were "lots of differences" but a vast majority of them are
> >>> > false-positives, not just those listed in the already massive "false
> >>> > positives" section.  I've been going through the non-"false positive"
> >>> > section and "resolving" specific items (via strike-through) with
> either
> >>> > (1)
> >>> > link to Jira fixing it or (2) comment as to the reason I believe it
> is a
> >>> > false-positive.
> >>> >
> >>> > I did not bother striking through the "false positives" section.
> >>> >
> >>> > At this point there are very few unresolved items in this list.
> Those
> >>> > items
> >>> > require more discussion
> >>> >
> >>> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero  >
> >>> > wrote:
> >>> >>
> >>> >> Thanks Gail, great job!
> >>> >> I fixed a trivial one, just a thousand to go ;)
> >>> >>
> >>> >> On 16 March 2018 at 23:09, Gail Badner  wrote:
> >>> >> > I've moved the document to
> >>> >> >
> >>> >> >
> >>> >> >
> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
> >>> >> > .
> >>> >> >
> >>> >> > Please let me know if you need an invite to view the document.
> >>> >> >
> >>> >> > The attachments are still at  https://developer.jboss.org/wiki/
> >>> >> > HibernateORMBinaryCompatibilityBetween51And53.
> >>> >> >
> >>> >> > Regards,
> >>> >> > Gail
> >>> >> >
> >>> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner  >
> >>> >> > wrote:
> >>> >> >
> >>> >> >> Hi,
> >>> >> >>
> >>> >> >> There were lots of differences in the compatibility report, so
> as a
> >>> >> >> first
> >>> >> >> step, I've excluded packages/classes that I considered SPI,
> >>> >> >> internal,
> >>> >> >> or
> >>> >> >> "grey area". This reduced the the differences to a more
> manageable
> >>> >> >> amount.
> >>> >> >>
> >>> >> >> You can see a summary of the incompatibilities along with
> suggested
> >>> >> >> mitigation at [1].
> >>> >> >>
> >>> >> >> The report is attached to [1], along with a zip with instructions
> >>> >> >> for
> >>> >> >> running the report.
> >>> >> >>
> >>> >> >> I believe there are some "false positives" in the report, and I
> have
> >>> >> >> documented them in the section, "False Positives?".
> >>> >> >>
> >>> >> >> Feel free to comment on the article.
> >>> >> >>
> >>> >> >> Thanks,
> >>> >> >> Gail
> >>> >> >>
> >>> >> >> [1]
> https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit
> >>> >> >> yBetween51And53
> >>> >> >>
> >>> >> >>
> >>> >> > ___
> >>> >> > 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
> >
> >
> >
> > --
> > - DML
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

[Sanne Grinovero]

On 22 March 2018 at 15:55, David Lloyd  wrote:
> This tool is usually pretty good; in fact I think it likely that it's
> the best of its kind.  The false positives are really a fairly recent
> development AFAIK; I don't recall hitting any when I ran it for our
> EJB changes a year or two ago.  It might be a good idea to contribute
> a fix for the problem upstream; it might even be relatively easy to
> do.  Or it could already be fixed.

Good to know, thanks. I might explore that next week.

Sanne

>
> On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole  wrote:
>> Not sure.  animal-sniffer is the other one I know, but not sure it would be
>> better.
>>
>> On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero 
>> wrote:
>>>
>>> To make sure all the noise form "false positives" won't get us to miss
>>> something, someone knows an alternative tool which can do better?
>>>
>>> Thanks,
>>> Sanne
>>>
>>>
>>> On 22 March 2018 at 14:22, Steve Ebersole  wrote:
>>> > Yes there were "lots of differences" but a vast majority of them are
>>> > false-positives, not just those listed in the already massive "false
>>> > positives" section.  I've been going through the non-"false positive"
>>> > section and "resolving" specific items (via strike-through) with either
>>> > (1)
>>> > link to Jira fixing it or (2) comment as to the reason I believe it is a
>>> > false-positive.
>>> >
>>> > I did not bother striking through the "false positives" section.
>>> >
>>> > At this point there are very few unresolved items in this list.  Those
>>> > items
>>> > require more discussion
>>> >
>>> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero 
>>> > wrote:
>>> >>
>>> >> Thanks Gail, great job!
>>> >> I fixed a trivial one, just a thousand to go ;)
>>> >>
>>> >> On 16 March 2018 at 23:09, Gail Badner  wrote:
>>> >> > I've moved the document to
>>> >> >
>>> >> >
>>> >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
>>> >> > .
>>> >> >
>>> >> > Please let me know if you need an invite to view the document.
>>> >> >
>>> >> > The attachments are still at  https://developer.jboss.org/wiki/
>>> >> > HibernateORMBinaryCompatibilityBetween51And53.
>>> >> >
>>> >> > Regards,
>>> >> > Gail
>>> >> >
>>> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner 
>>> >> > wrote:
>>> >> >
>>> >> >> Hi,
>>> >> >>
>>> >> >> There were lots of differences in the compatibility report, so as a
>>> >> >> first
>>> >> >> step, I've excluded packages/classes that I considered SPI,
>>> >> >> internal,
>>> >> >> or
>>> >> >> "grey area". This reduced the the differences to a more manageable
>>> >> >> amount.
>>> >> >>
>>> >> >> You can see a summary of the incompatibilities along with suggested
>>> >> >> mitigation at [1].
>>> >> >>
>>> >> >> The report is attached to [1], along with a zip with instructions
>>> >> >> for
>>> >> >> running the report.
>>> >> >>
>>> >> >> I believe there are some "false positives" in the report, and I have
>>> >> >> documented them in the section, "False Positives?".
>>> >> >>
>>> >> >> Feel free to comment on the article.
>>> >> >>
>>> >> >> Thanks,
>>> >> >> Gail
>>> >> >>
>>> >> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit
>>> >> >> yBetween51And53
>>> >> >>
>>> >> >>
>>> >> > ___
>>> >> > 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
>
>
>
> --
> - DML
___
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 22 March 2018 at 15:36, Emmanuel Bernard  wrote:
> As we discussed on the phone, I am skeptical of the custom HSearch backend
> for it:
> - it would be the only database doing that
> - it’s a lot of work that would probably be best spent improving the
> Infinispan remote query FT APIs
> - once there it will be a maintenance burden.

Thanks for clarifying. Then we won't create that in Search 6, at least
not until we have a better proposal.

The take away from this thread is that we don't want to map Hibernate
Search annotations from the domain model directly on the protobuf.

We can explore other ways to expose Infinispan's capabilities which
are less confusing.

Sanne

>
> Emmanuel
>
> On 22 Mar 2018, at 10:46, Sanne Grinovero  wrote:
>
> On 22 March 2018 at 07:41, Emmanuel Bernard  wrote:
>
>
> On 20 Mar 2018, at 12:41, Sanne Grinovero  wrote:
>
>
>
> 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?
>
>
>
> I did, it’s right below :) Granted that’s an option C.
>
>
> /The/ proposal in my first email is to have an Hibernate Search 6
> "backend" to support Infinispan Remote.
>
> I see no comments on that, but it's ok since it looks like we agree on
> the problems I had already listed.
>
> Thanks,
> Sanne
>
>
>
>
>
> 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 

Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

[David Lloyd]

This tool is usually pretty good; in fact I think it likely that it's
the best of its kind.  The false positives are really a fairly recent
development AFAIK; I don't recall hitting any when I ran it for our
EJB changes a year or two ago.  It might be a good idea to contribute
a fix for the problem upstream; it might even be relatively easy to
do.  Or it could already be fixed.

On Thu, Mar 22, 2018 at 10:37 AM, Steve Ebersole  wrote:
> Not sure.  animal-sniffer is the other one I know, but not sure it would be
> better.
>
> On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero 
> wrote:
>>
>> To make sure all the noise form "false positives" won't get us to miss
>> something, someone knows an alternative tool which can do better?
>>
>> Thanks,
>> Sanne
>>
>>
>> On 22 March 2018 at 14:22, Steve Ebersole  wrote:
>> > Yes there were "lots of differences" but a vast majority of them are
>> > false-positives, not just those listed in the already massive "false
>> > positives" section.  I've been going through the non-"false positive"
>> > section and "resolving" specific items (via strike-through) with either
>> > (1)
>> > link to Jira fixing it or (2) comment as to the reason I believe it is a
>> > false-positive.
>> >
>> > I did not bother striking through the "false positives" section.
>> >
>> > At this point there are very few unresolved items in this list.  Those
>> > items
>> > require more discussion
>> >
>> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero 
>> > wrote:
>> >>
>> >> Thanks Gail, great job!
>> >> I fixed a trivial one, just a thousand to go ;)
>> >>
>> >> On 16 March 2018 at 23:09, Gail Badner  wrote:
>> >> > I've moved the document to
>> >> >
>> >> >
>> >> > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
>> >> > .
>> >> >
>> >> > Please let me know if you need an invite to view the document.
>> >> >
>> >> > The attachments are still at  https://developer.jboss.org/wiki/
>> >> > HibernateORMBinaryCompatibilityBetween51And53.
>> >> >
>> >> > Regards,
>> >> > Gail
>> >> >
>> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner 
>> >> > wrote:
>> >> >
>> >> >> Hi,
>> >> >>
>> >> >> There were lots of differences in the compatibility report, so as a
>> >> >> first
>> >> >> step, I've excluded packages/classes that I considered SPI,
>> >> >> internal,
>> >> >> or
>> >> >> "grey area". This reduced the the differences to a more manageable
>> >> >> amount.
>> >> >>
>> >> >> You can see a summary of the incompatibilities along with suggested
>> >> >> mitigation at [1].
>> >> >>
>> >> >> The report is attached to [1], along with a zip with instructions
>> >> >> for
>> >> >> running the report.
>> >> >>
>> >> >> I believe there are some "false positives" in the report, and I have
>> >> >> documented them in the section, "False Positives?".
>> >> >>
>> >> >> Feel free to comment on the article.
>> >> >>
>> >> >> Thanks,
>> >> >> Gail
>> >> >>
>> >> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit
>> >> >> yBetween51And53
>> >> >>
>> >> >>
>> >> > ___
>> >> > 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



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

Re: [hibernate-dev] Why do we have the date in the URL of blog posts?

[Emmanuel Bernard]

I don’t think spending the n hours on outweighs the explained benefits so I 
would keep it that way.
The reason I had the dates were because blogs are time sensitive (like any 
content really), and it avoids or reduces the risk of slug collision for which 
we would need to implement a workaround for.

> On 22 Mar 2018, at 15:18, Guillaume Smet  wrote:
> 
> On Thu, Mar 22, 2018 at 2:39 PM, Gunnar Morling 
> wrote:
> 
>> Note I'm not suggesting to change any existing URLs. Rather my question is,
>> should we go to the date-less schema for new posts going forward.
>> 
> 
> Personally I like having the date information in the URL but I won't fight
> for it.
> 
> The only thing is I want to keep the on disk format as it is i.e. with the
> dates at the start of the file names. It's really easier to find the posts
> this way.
> 
> Apart from that, I don't really care.
> 
> By the way, this is me not volunteering to do the work :).
> 
> -- 
> 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] API differences in Hibernate ORM 5.1 vs 5.3

[Steve Ebersole]

Not sure.  animal-sniffer is the other one I know, but not sure it would be
better.

On Thu, Mar 22, 2018 at 10:21 AM Sanne Grinovero 
wrote:

> To make sure all the noise form "false positives" won't get us to miss
> something, someone knows an alternative tool which can do better?
>
> Thanks,
> Sanne
>
>
> On 22 March 2018 at 14:22, Steve Ebersole  wrote:
> > Yes there were "lots of differences" but a vast majority of them are
> > false-positives, not just those listed in the already massive "false
> > positives" section.  I've been going through the non-"false positive"
> > section and "resolving" specific items (via strike-through) with either
> (1)
> > link to Jira fixing it or (2) comment as to the reason I believe it is a
> > false-positive.
> >
> > I did not bother striking through the "false positives" section.
> >
> > At this point there are very few unresolved items in this list.  Those
> items
> > require more discussion
> >
> > On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero 
> wrote:
> >>
> >> Thanks Gail, great job!
> >> I fixed a trivial one, just a thousand to go ;)
> >>
> >> On 16 March 2018 at 23:09, Gail Badner  wrote:
> >> > I've moved the document to
> >> >
> >> >
> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
> >> > .
> >> >
> >> > Please let me know if you need an invite to view the document.
> >> >
> >> > The attachments are still at  https://developer.jboss.org/wiki/
> >> > HibernateORMBinaryCompatibilityBetween51And53.
> >> >
> >> > Regards,
> >> > Gail
> >> >
> >> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner 
> >> > wrote:
> >> >
> >> >> Hi,
> >> >>
> >> >> There were lots of differences in the compatibility report, so as a
> >> >> first
> >> >> step, I've excluded packages/classes that I considered SPI, internal,
> >> >> or
> >> >> "grey area". This reduced the the differences to a more manageable
> >> >> amount.
> >> >>
> >> >> You can see a summary of the incompatibilities along with suggested
> >> >> mitigation at [1].
> >> >>
> >> >> The report is attached to [1], along with a zip with instructions for
> >> >> running the report.
> >> >>
> >> >> I believe there are some "false positives" in the report, and I have
> >> >> documented them in the section, "False Positives?".
> >> >>
> >> >> Feel free to comment on the article.
> >> >>
> >> >> Thanks,
> >> >> Gail
> >> >>
> >> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit
> >> >> yBetween51And53
> >> >>
> >> >>
> >> > ___
> >> > 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] Hibernate OGM mapping for "server side Hibernate Search" via Infinispan Remote

[Emmanuel Bernard]

As we discussed on the phone, I am skeptical of the custom HSearch backend for 
it:
- it would be the only database doing that
- it’s a lot of work that would probably be best spent improving the Infinispan 
remote query FT APIs
- once there it will be a maintenance burden.

Emmanuel

> On 22 Mar 2018, at 10:46, Sanne Grinovero  wrote:
> 
> On 22 March 2018 at 07:41, Emmanuel Bernard  > wrote:
>> 
>> On 20 Mar 2018, at 12:41, Sanne Grinovero  wrote:
>> 
>> 
>> 
>> 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?
>> 
>> 
>> 
>> I did, it’s right below :) Granted that’s an option C.
> 
> /The/ proposal in my first email is to have an Hibernate Search 6
> "backend" to support Infinispan Remote.
> 
> I see no comments on that, but it's ok since it looks like we agree on
> the problems I had already listed.
> 
> Thanks,
> Sanne
> 
>> 
>> 
>>> 
>>> 
>>> 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 

Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

[Sanne Grinovero]

To make sure all the noise form "false positives" won't get us to miss
something, someone knows an alternative tool which can do better?

Thanks,
Sanne


On 22 March 2018 at 14:22, Steve Ebersole  wrote:
> Yes there were "lots of differences" but a vast majority of them are
> false-positives, not just those listed in the already massive "false
> positives" section.  I've been going through the non-"false positive"
> section and "resolving" specific items (via strike-through) with either (1)
> link to Jira fixing it or (2) comment as to the reason I believe it is a
> false-positive.
>
> I did not bother striking through the "false positives" section.
>
> At this point there are very few unresolved items in this list.  Those items
> require more discussion
>
> On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero  wrote:
>>
>> Thanks Gail, great job!
>> I fixed a trivial one, just a thousand to go ;)
>>
>> On 16 March 2018 at 23:09, Gail Badner  wrote:
>> > I've moved the document to
>> >
>> > https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
>> > .
>> >
>> > Please let me know if you need an invite to view the document.
>> >
>> > The attachments are still at  https://developer.jboss.org/wiki/
>> > HibernateORMBinaryCompatibilityBetween51And53.
>> >
>> > Regards,
>> > Gail
>> >
>> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner 
>> > wrote:
>> >
>> >> Hi,
>> >>
>> >> There were lots of differences in the compatibility report, so as a
>> >> first
>> >> step, I've excluded packages/classes that I considered SPI, internal,
>> >> or
>> >> "grey area". This reduced the the differences to a more manageable
>> >> amount.
>> >>
>> >> You can see a summary of the incompatibilities along with suggested
>> >> mitigation at [1].
>> >>
>> >> The report is attached to [1], along with a zip with instructions for
>> >> running the report.
>> >>
>> >> I believe there are some "false positives" in the report, and I have
>> >> documented them in the section, "False Positives?".
>> >>
>> >> Feel free to comment on the article.
>> >>
>> >> Thanks,
>> >> Gail
>> >>
>> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit
>> >> yBetween51And53
>> >>
>> >>
>> > ___
>> > 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] Hibernate ORM 5.3 CR2 ?

[andrea boriero]

Related with the TypeConfiguration and BootstrapContext work, I have just
made a PR targeting your last comments, but I need to know if the work done
it's fine and especially if it is enough to be considered done and then
integrated.

On 22 March 2018 at 14:15, Steve Ebersole  wrote:

> Still waiting for feedback on the PR or Jira.  I will integrate upstream
> today if I don't hear replies needing changes
>
> But regardless, this is not the only change CR2 is waiting on as I
> mentioned before
>
>
> On Thu, Mar 22, 2018, 8:54 AM Sanne Grinovero  wrote:
>
> > Could you help us understand. None of the SPI changes have been merged
> > in master yet?
> >
> > On 22 March 2018 at 13:39, Steve Ebersole  wrote:
> > > Then you'll have to wait.  Seems like snapshot is better than waiting
> > but of
> > > course your opinion seems just waiting is better...
> > >
> > > On Thu, Mar 22, 2018 at 8:34 AM Sanne Grinovero 
> > wrote:
> > >>
> > >>
> > >> No, snapshots are confusing when you need multiple people to
> collaborate
> > >> on a POC.
> > >>
> > >> It's not clear if a patch will work the same to others and it's
> > >> unpractical to match to a specific source commit.
> > >>
> > >> Why would we ever publish CRs if SNAPSHOTS are the same.
> > >>
> > >> On Thu, 22 Mar 2018, 13:17 Steve Ebersole, 
> wrote:
> > >>>
> > >>> Like a snapshot?
> > >>>
> > >>> On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero 
> > >>> wrote:
> > 
> >  On 22 March 2018 at 12:18, Steve Ebersole 
> > wrote:
> >  > There is already a branch that contains these changes that they
> can
> >  > work
> >  > with... no need to wait for a CR.  I still want to let Andrea
> finish
> >  > the
> >  > work on TypeConfiguration and BootstrapContext before we cut CR2.
> > 
> >  It would help to have a tagged release which can be consumed from
> > Maven.
> > 
> >  Could we not tag this as CR2 and whatever else is coming will be
> > another
> >  CRx ?
> > 
> >  I can do this release if that helps.
> > 
> >  Thanks,
> >  Sanne
> > 
> >  >
> >  > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero <
> > sa...@hibernate.org>
> >  > wrote:
> >  >>
> >  >> Steve, all,
> >  >>
> >  >> would it be possible to tag a CR2 as soon as the Caching SPI
> > changes
> >  >> are complete?
> >  >>
> >  >> That would help the Infinispan team so they can get started
> >  >> immediately on their side of things.
> >  >>
> >  >> Thanks,
> >  >> Sanne
> >
> ___
> 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] Why do we have the date in the URL of blog posts?

[Guillaume Smet]

On Thu, Mar 22, 2018 at 2:39 PM, Gunnar Morling 
wrote:

> Note I'm not suggesting to change any existing URLs. Rather my question is,
> should we go to the date-less schema for new posts going forward.
>

Personally I like having the date information in the URL but I won't fight
for it.

The only thing is I want to keep the on disk format as it is i.e. with the
dates at the start of the file names. It's really easier to find the posts
this way.

Apart from that, I don't really care.

By the way, this is me not volunteering to do the work :).

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

Re: [hibernate-dev] API differences in Hibernate ORM 5.1 vs 5.3

[Steve Ebersole]

Yes there were "lots of differences" but a vast majority of them are
false-positives, not just those listed in the already massive "false
positives" section.  I've been going through the non-"false positive"
section and "resolving" specific items (via strike-through) with either (1)
link to Jira fixing it or (2) comment as to the reason I believe it is a
false-positive.

I did not bother striking through the "false positives" section.

At this point there are very few unresolved items in this list.  Those
items require more discussion

On Fri, Mar 16, 2018 at 6:37 PM Sanne Grinovero  wrote:

> Thanks Gail, great job!
> I fixed a trivial one, just a thousand to go ;)
>
> On 16 March 2018 at 23:09, Gail Badner  wrote:
> > I've moved the document to
> >
> https://docs.google.com/document/d/1jH0znbYwgvGKHC-110zcjRaXLllBsvRKw-pdHrMzRzw
> > .
> >
> > Please let me know if you need an invite to view the document.
> >
> > The attachments are still at  https://developer.jboss.org/wiki/
> > HibernateORMBinaryCompatibilityBetween51And53.
> >
> > Regards,
> > Gail
> >
> > On Fri, Mar 16, 2018 at 12:36 AM, Gail Badner 
> wrote:
> >
> >> Hi,
> >>
> >> There were lots of differences in the compatibility report, so as a
> first
> >> step, I've excluded packages/classes that I considered SPI, internal, or
> >> "grey area". This reduced the the differences to a more manageable
> amount.
> >>
> >> You can see a summary of the incompatibilities along with suggested
> >> mitigation at [1].
> >>
> >> The report is attached to [1], along with a zip with instructions for
> >> running the report.
> >>
> >> I believe there are some "false positives" in the report, and I have
> >> documented them in the section, "False Positives?".
> >>
> >> Feel free to comment on the article.
> >>
> >> Thanks,
> >> Gail
> >>
> >> [1] https://developer.jboss.org/wiki/HibernateORMBinaryCompatibilit
> >> yBetween51And53
> >>
> >>
> > ___
> > 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] Hibernate ORM 5.3 CR2 ?

[Steve Ebersole]

Still waiting for feedback on the PR or Jira.  I will integrate upstream
today if I don't hear replies needing changes

But regardless, this is not the only change CR2 is waiting on as I
mentioned before


On Thu, Mar 22, 2018, 8:54 AM Sanne Grinovero  wrote:

> Could you help us understand. None of the SPI changes have been merged
> in master yet?
>
> On 22 March 2018 at 13:39, Steve Ebersole  wrote:
> > Then you'll have to wait.  Seems like snapshot is better than waiting
> but of
> > course your opinion seems just waiting is better...
> >
> > On Thu, Mar 22, 2018 at 8:34 AM Sanne Grinovero 
> wrote:
> >>
> >>
> >> No, snapshots are confusing when you need multiple people to collaborate
> >> on a POC.
> >>
> >> It's not clear if a patch will work the same to others and it's
> >> unpractical to match to a specific source commit.
> >>
> >> Why would we ever publish CRs if SNAPSHOTS are the same.
> >>
> >> On Thu, 22 Mar 2018, 13:17 Steve Ebersole,  wrote:
> >>>
> >>> Like a snapshot?
> >>>
> >>> On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero 
> >>> wrote:
> 
>  On 22 March 2018 at 12:18, Steve Ebersole 
> wrote:
>  > There is already a branch that contains these changes that they can
>  > work
>  > with... no need to wait for a CR.  I still want to let Andrea finish
>  > the
>  > work on TypeConfiguration and BootstrapContext before we cut CR2.
> 
>  It would help to have a tagged release which can be consumed from
> Maven.
> 
>  Could we not tag this as CR2 and whatever else is coming will be
> another
>  CRx ?
> 
>  I can do this release if that helps.
> 
>  Thanks,
>  Sanne
> 
>  >
>  > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero <
> sa...@hibernate.org>
>  > wrote:
>  >>
>  >> Steve, all,
>  >>
>  >> would it be possible to tag a CR2 as soon as the Caching SPI
> changes
>  >> are complete?
>  >>
>  >> That would help the Infinispan team so they can get started
>  >> immediately on their side of things.
>  >>
>  >> Thanks,
>  >> Sanne
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 5.3 CR2 ?

[Sanne Grinovero]

Could you help us understand. None of the SPI changes have been merged
in master yet?

On 22 March 2018 at 13:39, Steve Ebersole  wrote:
> Then you'll have to wait.  Seems like snapshot is better than waiting but of
> course your opinion seems just waiting is better...
>
> On Thu, Mar 22, 2018 at 8:34 AM Sanne Grinovero  wrote:
>>
>>
>> No, snapshots are confusing when you need multiple people to collaborate
>> on a POC.
>>
>> It's not clear if a patch will work the same to others and it's
>> unpractical to match to a specific source commit.
>>
>> Why would we ever publish CRs if SNAPSHOTS are the same.
>>
>> On Thu, 22 Mar 2018, 13:17 Steve Ebersole,  wrote:
>>>
>>> Like a snapshot?
>>>
>>> On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero 
>>> wrote:

 On 22 March 2018 at 12:18, Steve Ebersole  wrote:
 > There is already a branch that contains these changes that they can
 > work
 > with... no need to wait for a CR.  I still want to let Andrea finish
 > the
 > work on TypeConfiguration and BootstrapContext before we cut CR2.

 It would help to have a tagged release which can be consumed from Maven.

 Could we not tag this as CR2 and whatever else is coming will be another
 CRx ?

 I can do this release if that helps.

 Thanks,
 Sanne

 >
 > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero 
 > wrote:
 >>
 >> Steve, all,
 >>
 >> would it be possible to tag a CR2 as soon as the Caching SPI changes
 >> are complete?
 >>
 >> That would help the Infinispan team so they can get started
 >> immediately on their side of things.
 >>
 >> Thanks,
 >> Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 5.3 CR2 ?

[Sanne Grinovero]

No, snapshots are confusing when you need multiple people to collaborate on
a POC.

It's not clear if a patch will work the same to others and it's unpractical
to match to a specific source commit.

Why would we ever publish CRs if SNAPSHOTS are the same.

On Thu, 22 Mar 2018, 13:17 Steve Ebersole,  wrote:

> Like a snapshot?
>
> On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero  wrote:
>
>> On 22 March 2018 at 12:18, Steve Ebersole  wrote:
>> > There is already a branch that contains these changes that they can work
>> > with... no need to wait for a CR.  I still want to let Andrea finish the
>> > work on TypeConfiguration and BootstrapContext before we cut CR2.
>>
>> It would help to have a tagged release which can be consumed from Maven.
>>
>> Could we not tag this as CR2 and whatever else is coming will be another
>> CRx ?
>>
>> I can do this release if that helps.
>>
>> Thanks,
>> Sanne
>>
>> >
>> > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero 
>> wrote:
>> >>
>> >> Steve, all,
>> >>
>> >> would it be possible to tag a CR2 as soon as the Caching SPI changes
>> >> are complete?
>> >>
>> >> That would help the Infinispan team so they can get started
>> >> immediately on their side of things.
>> >>
>> >> Thanks,
>> >> Sanne
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 5.3 CR2 ?

[Steve Ebersole]

Like a snapshot?

On Thu, Mar 22, 2018, 7:22 AM Sanne Grinovero  wrote:

> On 22 March 2018 at 12:18, Steve Ebersole  wrote:
> > There is already a branch that contains these changes that they can work
> > with... no need to wait for a CR.  I still want to let Andrea finish the
> > work on TypeConfiguration and BootstrapContext before we cut CR2.
>
> It would help to have a tagged release which can be consumed from Maven.
>
> Could we not tag this as CR2 and whatever else is coming will be another
> CRx ?
>
> I can do this release if that helps.
>
> Thanks,
> Sanne
>
> >
> > On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero 
> wrote:
> >>
> >> Steve, all,
> >>
> >> would it be possible to tag a CR2 as soon as the Caching SPI changes
> >> are complete?
> >>
> >> That would help the Infinispan team so they can get started
> >> immediately on their side of things.
> >>
> >> Thanks,
> >> Sanne
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Why do we have the date in the URL of blog posts?

[Davide D'Alto]

By the way, if some articles are more technical and we put some effort
 in keeping them up-to-date,
we could put them in a separate section and just post in the blog
about their existence and updates.

Davide

On Thu, Mar 22, 2018 at 1:14 PM, Davide D'Alto  wrote:
>> I personally don't see the problem with dates in URLs. I don't see any
>> problem with not having them, either. But I do see a problem with changing
>> the URL scheme: potential dead links, SEO nightmare... We would need a damn
>> good reason to do it, and I'm not sure those you mentioned are enough...
>
> +1
>
>> In our case, the data works against us as people might think an article is
>> outdated by just inspecting the slug and thinking that
>> a 3 year-old article might not be relevant anymore.
>
> Even if you remove it from the URL, you still have the published date
> on every article. The user can still see when the article has been
> written.
> This makes sense because we are talking about blog posts.
>
> And this argument can also be used in favor of dates:
> without the date, you might give the impression that the article is
> always up-to-date and I don't think that's realistic.
>
> I'm not against changing it, but, unless we have some real reasons
> related to SEO or similar,
> I wouldn't worry too much. Most users are probably more interested to
> know when the article has been updated anyway (and not when has been
> published).
>
> Davide
>
> On Thu, Mar 22, 2018 at 12:24 PM, Yoann Rodiere  wrote:
>>> The data in the post slug only makes sense for news sites where posts are
>> highly associated to a given date.
>>
>> A lot of our posts are. Release announcements and weekly newsletters in
>> particular.
>>
>> I personally don't see the problem with dates in URLs. I don't see any
>> problem with not having them, either. But I do see a problem with changing
>> the URL scheme: potential dead links, SEO nightmare... We would need a damn
>> good reason to do it, and I'm not sure those you mentioned are enough...
>>
>> On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea  wrote:
>>
>>> Hi,
>>>
>>> The data in the post slug only makes sense for news sites where posts are
>>> highly associated to a given date.
>>>
>>> In our case, the data works against us as people might think an article is
>>> outdated by just inspecting the slug and thinking that
>>> a 3 year-old article might not be relevant anymore.
>>>
>>> It's better if we use simple slug names that capture the article focus
>>> keywords and remove the date altogether.
>>>
>>> Vlad
>>>
>>> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling 
>>> wrote:
>>>
>>> > Hi,
>>> >
>>> > While talking to a few bloggers from the Java ecosphere at JavaLand last
>>> > week, the question came up why we have the date in the URL of blog posts.
>>> >
>>> > Arguably, it doesn't add value there (we show the date on the actual
>>> posts
>>> > themselves), and makes the URLs slightly worse to read. In particular, we
>>> > don't allow for browsing posts by year or month (e.g.
>>> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting
>>> the
>>> > date would also make the original idea of the URL fly again ("in relation
>>> > to xyz").
>>> >
>>> > Anyone with thoughts whether we should change the scheme (keeping
>>> existing
>>> > ones of course)?
>>> >
>>> > That all said, I've no idea whether the date in there is good to have or
>>> > not in terms of SEO. I suppose it doesn't matter.
>>> >
>>> > --Gunnar
>>> > ___
>>> > 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
>>>
>> --
>> 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Why do we have the date in the URL of blog posts?

[Davide D'Alto]

> I personally don't see the problem with dates in URLs. I don't see any
> problem with not having them, either. But I do see a problem with changing
> the URL scheme: potential dead links, SEO nightmare... We would need a damn
> good reason to do it, and I'm not sure those you mentioned are enough...

+1

> In our case, the data works against us as people might think an article is
> outdated by just inspecting the slug and thinking that
> a 3 year-old article might not be relevant anymore.

Even if you remove it from the URL, you still have the published date
on every article. The user can still see when the article has been
written.
This makes sense because we are talking about blog posts.

And this argument can also be used in favor of dates:
without the date, you might give the impression that the article is
always up-to-date and I don't think that's realistic.

I'm not against changing it, but, unless we have some real reasons
related to SEO or similar,
I wouldn't worry too much. Most users are probably more interested to
know when the article has been updated anyway (and not when has been
published).

Davide

On Thu, Mar 22, 2018 at 12:24 PM, Yoann Rodiere  wrote:
>> The data in the post slug only makes sense for news sites where posts are
> highly associated to a given date.
>
> A lot of our posts are. Release announcements and weekly newsletters in
> particular.
>
> I personally don't see the problem with dates in URLs. I don't see any
> problem with not having them, either. But I do see a problem with changing
> the URL scheme: potential dead links, SEO nightmare... We would need a damn
> good reason to do it, and I'm not sure those you mentioned are enough...
>
> On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea  wrote:
>
>> Hi,
>>
>> The data in the post slug only makes sense for news sites where posts are
>> highly associated to a given date.
>>
>> In our case, the data works against us as people might think an article is
>> outdated by just inspecting the slug and thinking that
>> a 3 year-old article might not be relevant anymore.
>>
>> It's better if we use simple slug names that capture the article focus
>> keywords and remove the date altogether.
>>
>> Vlad
>>
>> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling 
>> wrote:
>>
>> > Hi,
>> >
>> > While talking to a few bloggers from the Java ecosphere at JavaLand last
>> > week, the question came up why we have the date in the URL of blog posts.
>> >
>> > Arguably, it doesn't add value there (we show the date on the actual
>> posts
>> > themselves), and makes the URLs slightly worse to read. In particular, we
>> > don't allow for browsing posts by year or month (e.g.
>> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting
>> the
>> > date would also make the original idea of the URL fly again ("in relation
>> > to xyz").
>> >
>> > Anyone with thoughts whether we should change the scheme (keeping
>> existing
>> > ones of course)?
>> >
>> > That all said, I've no idea whether the date in there is good to have or
>> > not in terms of SEO. I suppose it doesn't matter.
>> >
>> > --Gunnar
>> > ___
>> > 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
>>
> --
> 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Defaultable service strategies

[Chris Cranford]

+1

Makes sense to me.

On 03/21/2018 02:42 PM, Steve Ebersole wrote:
> Thoughts on allowing certain services to be defaulted to the single
> implementor registered with the `StrategySelector` service when there is
> just one?
>
> For example, when resolving the RegionFactory unless both (a)
> `hibernate.cache.region.factory_class` and (b) one of
> `hibernate.cache.use_second_level_cache` or
> `hibernate.cache.use_query_cache` are defined caching support will be
> disabled.  What I am proposing would kick in in this case and check to see
> if there is just a single RegionFactory registered with the
> StrategySelector and if so use that one.
>
> It would allow Hibernate to more seamlessly operate as a JPA provider too,
> as currently to use caching with JPA and Hibernate users have to do the
> normal JPA stuff and then also define these Hibernate settings.  It would
> be nicer if they could just do the JPA stuff.
> ___
> 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] Why do we have the date in the URL of blog posts?

[Vlad Mihalcea]

I also switched my blog from dates to simple slugs at the beginning of the
year.

As long as you add the proper Redirection rules in .htaccess_posts, it
shouldn't be any problem.

Google does not penalize 301 redirects, so you don't lose any SEO ranking
if you use 301 redirects.

We can also change the slug names for new articles only while leaving the
old ones as-is.

Vlad

On Thu, Mar 22, 2018 at 2:24 PM, Yoann Rodiere  wrote:

> > The data in the post slug only makes sense for news sites where posts are
> highly associated to a given date.
>
> A lot of our posts are. Release announcements and weekly newsletters in
> particular.
>
> I personally don't see the problem with dates in URLs. I don't see any
> problem with not having them, either. But I do see a problem with changing
> the URL scheme: potential dead links, SEO nightmare... We would need a damn
> good reason to do it, and I'm not sure those you mentioned are enough...
>
> On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea 
> wrote:
>
>> Hi,
>>
>> The data in the post slug only makes sense for news sites where posts are
>> highly associated to a given date.
>>
>> In our case, the data works against us as people might think an article is
>> outdated by just inspecting the slug and thinking that
>> a 3 year-old article might not be relevant anymore.
>>
>> It's better if we use simple slug names that capture the article focus
>> keywords and remove the date altogether.
>>
>> Vlad
>>
>> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling 
>> wrote:
>>
>> > Hi,
>> >
>> > While talking to a few bloggers from the Java ecosphere at JavaLand last
>> > week, the question came up why we have the date in the URL of blog
>> posts.
>> >
>> > Arguably, it doesn't add value there (we show the date on the actual
>> posts
>> > themselves), and makes the URLs slightly worse to read. In particular,
>> we
>> > don't allow for browsing posts by year or month (e.g.
>> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting
>> the
>> > date would also make the original idea of the URL fly again ("in
>> relation
>> > to xyz").
>> >
>> > Anyone with thoughts whether we should change the scheme (keeping
>> existing
>> > ones of course)?
>> >
>> > That all said, I've no idea whether the date in there is good to have or
>> > not in terms of SEO. I suppose it doesn't matter.
>> >
>> > --Gunnar
>> > ___
>> > 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
>>
> --
> 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

Re: [hibernate-dev] Why do we have the date in the URL of blog posts?

[Yoann Rodiere]

> The data in the post slug only makes sense for news sites where posts are
highly associated to a given date.

A lot of our posts are. Release announcements and weekly newsletters in
particular.

I personally don't see the problem with dates in URLs. I don't see any
problem with not having them, either. But I do see a problem with changing
the URL scheme: potential dead links, SEO nightmare... We would need a damn
good reason to do it, and I'm not sure those you mentioned are enough...

On Thu, 22 Mar 2018 at 12:29 Vlad Mihalcea  wrote:

> Hi,
>
> The data in the post slug only makes sense for news sites where posts are
> highly associated to a given date.
>
> In our case, the data works against us as people might think an article is
> outdated by just inspecting the slug and thinking that
> a 3 year-old article might not be relevant anymore.
>
> It's better if we use simple slug names that capture the article focus
> keywords and remove the date altogether.
>
> Vlad
>
> On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling 
> wrote:
>
> > Hi,
> >
> > While talking to a few bloggers from the Java ecosphere at JavaLand last
> > week, the question came up why we have the date in the URL of blog posts.
> >
> > Arguably, it doesn't add value there (we show the date on the actual
> posts
> > themselves), and makes the URLs slightly worse to read. In particular, we
> > don't allow for browsing posts by year or month (e.g.
> > http://in.relation.to/2018/), so it's even a bit misleading. Omitting
> the
> > date would also make the original idea of the URL fly again ("in relation
> > to xyz").
> >
> > Anyone with thoughts whether we should change the scheme (keeping
> existing
> > ones of course)?
> >
> > That all said, I've no idea whether the date in there is good to have or
> > not in terms of SEO. I suppose it doesn't matter.
> >
> > --Gunnar
> > ___
> > 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
>
-- 
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

Re: [hibernate-dev] Hibernate ORM 5.3 CR2 ?

[Sanne Grinovero]

On 22 March 2018 at 12:18, Steve Ebersole  wrote:
> There is already a branch that contains these changes that they can work
> with... no need to wait for a CR.  I still want to let Andrea finish the
> work on TypeConfiguration and BootstrapContext before we cut CR2.

It would help to have a tagged release which can be consumed from Maven.

Could we not tag this as CR2 and whatever else is coming will be another CRx ?

I can do this release if that helps.

Thanks,
Sanne

>
> On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero  wrote:
>>
>> Steve, all,
>>
>> would it be possible to tag a CR2 as soon as the Caching SPI changes
>> are complete?
>>
>> That would help the Infinispan team so they can get started
>> immediately on their side of things.
>>
>> Thanks,
>> Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate ORM 5.3 CR2 ?

[Steve Ebersole]

There is already a branch that contains these changes that they can work
with... no need to wait for a CR.  I still want to let Andrea finish the
work on TypeConfiguration and BootstrapContext before we cut CR2.

On Thu, Mar 22, 2018 at 7:17 AM Sanne Grinovero  wrote:

> Steve, all,
>
> would it be possible to tag a CR2 as soon as the Caching SPI changes
> are complete?
>
> That would help the Infinispan team so they can get started
> immediately on their side of things.
>
> Thanks,
> Sanne
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate ORM 5.3 CR2 ?

[Sanne Grinovero]

Steve, all,

would it be possible to tag a CR2 as soon as the Caching SPI changes
are complete?

That would help the Infinispan team so they can get started
immediately on their side of things.

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

Re: [hibernate-dev] Starting 5.2.16 release

[Sanne Grinovero]

That's an interesting idea, especially as these messages like "please
don't push" are highlighting the current process is fragile.

Personally I quite like the fact that I can see the previous tags in
my history during development but I guess it's just a habit. What do
others think?

On 22 March 2018 at 11:25, Jordan Gigov  wrote:
> I was thinking to propose this part of the release process gets changed a
> bit, so that the commit of a "Final" version never goes into "master", but
> remains on a tag.
>
> Something like this:
> # detach head
> git checkout
> # edit file and change hibernateVersion
> editor gradle/base-information.gradle
> # commit while in detached state
> git add . && git commit
> # add tag to current untracked HEAD
> git tag 5.whatever
> # push the tag
> git push origin refs/tags/5.whatever
>
>
> This way the release versions do not pollute the branches, but grow besides
> them, and you don't need to issue "do not push" warnings.
>
> On 22 March 2018 at 13:03, andrea boriero  wrote:
>
>> *Please do not push anything to 5.2 branch.Thanks,Andrea*
>> ___
>> 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] Starting 5.2.16 release

[Jordan Gigov]

I was thinking to propose this part of the release process gets changed a
bit, so that the commit of a "Final" version never goes into "master", but
remains on a tag.

Something like this:
# detach head
git checkout
# edit file and change hibernateVersion
editor gradle/base-information.gradle
# commit while in detached state
git add . && git commit
# add tag to current untracked HEAD
git tag 5.whatever
# push the tag
git push origin refs/tags/5.whatever


This way the release versions do not pollute the branches, but grow besides
them, and you don't need to issue "do not push" warnings.

On 22 March 2018 at 13:03, andrea boriero  wrote:

> *Please do not push anything to 5.2 branch.Thanks,Andrea*
> ___
> 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] Starting 5.2.16 release

[andrea boriero]

*Please do not push anything to 5.2 branch.Thanks,Andrea*
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Why do we have the date in the URL of blog posts?

[Vlad Mihalcea]

Hi,

The data in the post slug only makes sense for news sites where posts are
highly associated to a given date.

In our case, the data works against us as people might think an article is
outdated by just inspecting the slug and thinking that
a 3 year-old article might not be relevant anymore.

It's better if we use simple slug names that capture the article focus
keywords and remove the date altogether.

Vlad

On Thu, Mar 22, 2018 at 10:23 AM, Gunnar Morling 
wrote:

> Hi,
>
> While talking to a few bloggers from the Java ecosphere at JavaLand last
> week, the question came up why we have the date in the URL of blog posts.
>
> Arguably, it doesn't add value there (we show the date on the actual posts
> themselves), and makes the URLs slightly worse to read. In particular, we
> don't allow for browsing posts by year or month (e.g.
> http://in.relation.to/2018/), so it's even a bit misleading. Omitting the
> date would also make the original idea of the URL fly again ("in relation
> to xyz").
>
> Anyone with thoughts whether we should change the scheme (keeping existing
> ones of course)?
>
> That all said, I've no idea whether the date in there is good to have or
> not in terms of SEO. I suppose it doesn't matter.
>
> --Gunnar
> ___
> 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 22 March 2018 at 07:41, Emmanuel Bernard  wrote:
>
> On 20 Mar 2018, at 12:41, Sanne Grinovero  wrote:
>
>
>
> 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?
>
>
>
> I did, it’s right below :) Granted that’s an option C.

/The/ proposal in my first email is to have an Hibernate Search 6
"backend" to support Infinispan Remote.

I see no comments on that, but it's ok since it looks like we agree on
the problems I had already listed.

Thanks,
Sanne

>
>
>>
>>
>> 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] Why do we have the date in the URL of blog posts?

[Gunnar Morling]

Hi,

While talking to a few bloggers from the Java ecosphere at JavaLand last
week, the question came up why we have the date in the URL of blog posts.

Arguably, it doesn't add value there (we show the date on the actual posts
themselves), and makes the URLs slightly worse to read. In particular, we
don't allow for browsing posts by year or month (e.g.
http://in.relation.to/2018/), so it's even a bit misleading. Omitting the
date would also make the original idea of the URL fly again ("in relation
to xyz").

Anyone with thoughts whether we should change the scheme (keeping existing
ones of course)?

That all said, I've no idea whether the date in there is good to have or
not in terms of SEO. I suppose it doesn't matter.

--Gunnar
___
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]

> On 20 Mar 2018, at 12:41, Sanne Grinovero  wrote:
> 
> 
> 
> 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?​
> 
> 

I did, it’s right below :) Granted that’s an option C.

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

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

[Emmanuel Bernard]

> On 20 Mar 2018, at 13:24, Guillaume Smet  wrote:
> 
> 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.

Readability is the root of all evil. I read that somewhere on the internet
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Async JDBC proposal

[Emmanuel Bernard]

Slides 8 explicitly says that it is not built on JDBC, is not a replacement but 
will live alongside.

> On 20 Mar 2018, at 22:17, Mark Rotteveel  wrote:
> 
> 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 
> 
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Async JDBC proposal

[Emmanuel Bernard]

Yep correct link, sorry about that :/
https://blogs.oracle.com/java/jdbc-next%3a-a-new-asynchronous-api-for-connecting-to-a-database
 



> On 20 Mar 2018, at 12:13, Radim Vansa  wrote:
> 
> 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 mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev