[hibernate-dev] HHH-7610 Embedded: emptiness and dirtiness

[Guillaume Smet]

Hi all,

So, after a long time without any issue (rest assured we were busy
anyway!), we got around a new problem we would like to fix in ORM:
HHH-7610 .

It's a long standing complaint about the embedded and the fact that
empty components are returned from the ORM.

We had the "good" idea to fix it by overriding the getter to set the
value to an empty object if null and it's not really a good one: we do
a lot of unnecessary updates due to the fact that our entities are
considered dirty.

A coworker of mine (Laurent CCed) followed the instructions given by
Steve in HHH-7610 to implement a configuration setting to return an
empty component if all its properties is null:
see 
https://github.com/openwide-java/hibernate-orm/commit/a219fd38c0a80e6bf0a5de41f31e49ee83f00ccf
-> we think this one should be ready to commit. It's for 4.3.x.
-> using all the tests with this new setting enabled triggers a few
errors but, after carefully reviewing them, they are all expected due
to the nature of this change.

We are wondering if we shouldn't also change the isDirty/equals...
stuff to consider 2 components equals if one is null and the other has
all its properties null: it sounds kinda logical to us considering ORM
already automatically transforms one to the other if we save then get
the entity.

We wrote a few tests to demonstrate the issue and we would like to
know if you would consider this a good idea or not to fix this in both
cases (settings on or off):
https://github.com/openwide-java/hibernate-orm/commit/ee913e79633d3a5ac9c5affdcb58ab3af780f71a

Thanks for your advice.

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

Re: [hibernate-dev] HHH-7610 Embedded: emptiness and dirtiness

[Guillaume Smet]

Hi!

Any interest in us pursuing this?

We are obviously committed to update the documentation once we have
validated it's the way to go.

Thanks for your feedback.

On Tue, Oct 14, 2014 at 3:23 PM, Guillaume Smet
 wrote:
> Hi all,
>
> So, after a long time without any issue (rest assured we were busy
> anyway!), we got around a new problem we would like to fix in ORM:
> HHH-7610 .
>
> It's a long standing complaint about the embedded and the fact that
> empty components are returned from the ORM.
>
> We had the "good" idea to fix it by overriding the getter to set the
> value to an empty object if null and it's not really a good one: we do
> a lot of unnecessary updates due to the fact that our entities are
> considered dirty.
>
> A coworker of mine (Laurent CCed) followed the instructions given by
> Steve in HHH-7610 to implement a configuration setting to return an
> empty component if all its properties is null:
> see 
> https://github.com/openwide-java/hibernate-orm/commit/a219fd38c0a80e6bf0a5de41f31e49ee83f00ccf
> -> we think this one should be ready to commit. It's for 4.3.x.
> -> using all the tests with this new setting enabled triggers a few
> errors but, after carefully reviewing them, they are all expected due
> to the nature of this change.
>
> We are wondering if we shouldn't also change the isDirty/equals...
> stuff to consider 2 components equals if one is null and the other has
> all its properties null: it sounds kinda logical to us considering ORM
> already automatically transforms one to the other if we save then get
> the entity.
>
> We wrote a few tests to demonstrate the issue and we would like to
> know if you would consider this a good idea or not to fix this in both
> cases (settings on or off):
> https://github.com/openwide-java/hibernate-orm/commit/ee913e79633d3a5ac9c5affdcb58ab3af780f71a
>
> Thanks for your advice.
>
> --
> Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HHH-7610 Embedded: emptiness and dirtiness

[Guillaume Smet]

Hi Steve,

On Fri, Oct 24, 2014 at 3:08 PM, Steve Ebersole  wrote:
> As to your specific question, yes I think what you propose makes sense.
> Namely, if this setting is enabled, I think it is reasonable to treat a null
> component reference and an empty component reference as equivalent.

Thanks for your feedback!

Isn't it even more reasonable to treat null and empty as equivalent in
the current behavior?

Currently, we have:
Entity with empty embedded -> save + get -> Entity with null
so we are considering that empty embedded and null are the exact same things.

If you set again the embedded to an empty one for various reasons,
it's going to be considered dirty again which is IMHO wrong.

I won't argue a lot about this as we will run all our applications
with this setting enabled but I think it will be a performance
improvement to fix this in the other case too.

Note that I'm not very familiar with these things so I might have
missed an obvious point.

We are going to fix the things you commented on Github, work on the
documentation and wait for your feedback on this specific point before
going further on this particular issue.

It would be nice to have it in the next 4.3.x release as we have an
application which is particularly affected by this issue.

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

Re: [hibernate-dev] HHH-7610 Embedded: emptiness and dirtiness

[Guillaume Smet]

On Fri, Oct 24, 2014 at 4:30 PM, Steve Ebersole  wrote:
> As for 4.3.x, for me that again goes back to this not being a bug.  4.3 is a
> maintenance branch now, meaning it should only include bug fixes in any
> releases.  So IMO this should not be part of the 4.3 branch.  I do want to
> have a discussion about possibly doing another 4.x release as a sort of
> incremental stepping stone to the 5.0 work on master.  The plan is to have
> that discussion next week, since quite a few of us will be meeting face to
> face.  I can see this being a part of that new branch if we end up doing it.

I kinda agree with you on the 4.3.x part even if it doesn't meet my
business requirements but I agree this is my problem!

But... I can't see the consistency of the current behavior:
- if your embedded is empty, you get null from the ORM when you save and get it
- but hey null and empty embedded are not the same so I will save your
entity again if you set it to an empty embedded

So my point is:
1/ I agree that changing the fact that Hibernate returns empty
components instead of null needs a configuration thingy in the 4.x
branch; I would personnally like it to be the default in 5.x;
2/ but the 2nd statement above should really be changed IMHO to be
consistent with the 1st one.

Anyway we'll try to come up with a sensible patch in the next few days
and we then will be able to decide what to do with it!

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

[hibernate-dev] Native query and auto-flush

[Guillaume Smet]

Hi!

Starting with HHH-8487, when we execute a native query, an auto-flush
is executed (and might be limited with addSynchronizedEntityClass and
allegates).

While I understand the rationale of this change, we are having a few
issues with this when the transaction opened is read-only which is the
case for all our read-only queries: Hibernate tries to flush the dirty
entities in a read-only transaction and fails.

The heart of the issue here is that we have dirty entities which
shouldn't be dirty (see my post on embedded and dirtiness) but I'm
wondering if it's a behavior which was missed by this patch or
something intentional. So I thought I might as well report it.

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

Re: [hibernate-dev] Search - HSEARCH-1580 - Dependency graph

[Guillaume Smet]

Hi Sanne,

On Fri, Aug 22, 2014 at 11:25 PM, Guillaume Smet
 wrote:
> We'll have the bandwidth starting from september 15th so if we have a
> release then, we'll start playing with 5.

If a new alpha of 5 can be released soon with the above fix, we will
be able to start using it in our in progress apps to provide feedback
on real apps.

Thanks!

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

Re: [hibernate-dev] Native query and auto-flush

[Guillaume Smet]

On Thu, Oct 30, 2014 at 2:56 PM, Steve Ebersole  wrote:
> Personally having entities dirtied as part of a read-only transaction sounds
> like an application bug to me.  We could try to detect a read-only
> transaction state (not sure how we'd do that across all cases) and
> circumvent the flush there, but that would add unnecessary overhead to
> applications that do the right thing.

They aren't dirtied as part of the read-only transaction per se but I
agree with you it's more an application bug (it's due to the way we're
dealing with empty embedded).

Just wanted to report it in case it was easy and free to test the
transaction status!
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] hibernate-dev Digest, Vol 100, Issue 8

[Guillaume Smet]

Hi Sanne,

I think Marc was confused by Steve's email.

Steve is talking about ORM 5, not Search 5.

-- 
Guillaume


On Fri, Oct 31, 2014 at 2:59 PM, Sanne Grinovero  wrote:
> Hi Marc,
> what does it mean Spring 2015 ? Is that a release of the Spring project?
> We plan to release Hibernate Search 5 by December, we can finally
> commit on a date as all blockers have been resolved (finally), so now
> we're in polishing and testing fase, back into time-boxing mode.
>
> -- Sanne
>
> On 31 October 2014 12:23, Marc Schipperheyn  wrote:
>> I'm disappointed to see Spring 2015 on HSEARCH 5.0. Especially given how
>> long Lucene 4 has been in the field (October 2012). HSEARCH seemed to be at
>> a standstill for most of this year.
>>
>> I would prefer to cut down on features to see it sooner, but I guess that's
>> not an option anymore. Also, I would say the risk is Lucene will run out of
>> 4.x-es and move on to 5.x
>>
>> Cheers,
>> Marc
>> ___
>> 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

[hibernate-dev] HHH-7610 - Embedded and nulls

[Guillaume Smet]

Hi all,

(sorry for the long silence, have been dealing with personal issues)

I have cycles next week and I would like to tackle this issue:
https://hibernate.atlassian.net/browse/HHH-7610

My colleague, Laurent Almeras, already worked on a patch here:
https://github.com/openwide-java/hibernate-orm/commits/embedded-empty-configuration
.

Steve gave us a few advices and we took them into account in the following
commits.

Should I rebase the patch and propose a PR? If so, for which branches?

As a lot of people asked for it, I would prefer it being integrated instead
of keeping a set of patches here at Open Wide.

Thanks for your feedback!

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

[hibernate-dev] Testing Hibernate 5: injecting a Spring managed interceptor

[Guillaume Smet]

Hi,

As I have cycles this week and next week, I thought I might as well do some
QA on Hibernate 5.

I'm still in the process of porting our code to 5 atm and I have a pattern
we used before I can't find an elegant way to port on Hibernate 5: this
pattern is used to inject a Spring managed interceptor.

We override the persistence provider to inject the interceptor in the
Hibernate configuration:
https://gist.github.com/gsmet/e8d3003344938b1d327b

I studied the new code for quite some time and I couldn't find a way to
inject my interceptor in 5.

Note that it's a pretty common usage in the Spring managed world.

Thanks for any guidance.

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

Re: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed interceptor

[Guillaume Smet]

Yup, populate(SessionFactoryBuilder, StandardServiceRegistry) was my
favorite spot too but it's currently private. Would you mind making it
protected?

Note that if we can do so without subclassing the said internal class, I'm
all ears :). This method was inspired by a blog post for 4.2 that I ported
to 4.3. It has the advantage of not being too intrusive.

-- 
Guillaume

On Thu, May 7, 2015 at 4:59 AM, Steve Ebersole  wrote:

> As outlined in
> http://docs.jboss.org/hibernate/orm/5.0/topical/html/bootstrap/LegacyBootstrapping.html#_migration,
>  Configuration#setInterceptor
> calls now map to the SessionFactoryBuilder#applyInterceptor method.  So
> really we need to look at choices for how to influence the Interceptor on
> SessionFactoryBuilder.  I say choices because there are a few ways.  The
> most appropriate way I think in your case (given that you already
> questionable subclass an internal class ;) would be to just override
> EntityManagerFactoryBuilderImpl#populate(SessionFactoryBuilder,
> StandardServiceRegistry) to apply your Interceptor.
>
> On Wed, May 6, 2015 at 3:21 PM, Guillaume Smet 
> wrote:
>
>> Hi,
>>
>> As I have cycles this week and next week, I thought I might as well do
>> some
>> QA on Hibernate 5.
>>
>> I'm still in the process of porting our code to 5 atm and I have a pattern
>> we used before I can't find an elegant way to port on Hibernate 5: this
>> pattern is used to inject a Spring managed interceptor.
>>
>> We override the persistence provider to inject the interceptor in the
>> Hibernate configuration:
>> https://gist.github.com/gsmet/e8d3003344938b1d327b
>>
>> I studied the new code for quite some time and I couldn't find a way to
>> inject my interceptor in 5.
>>
>> Note that it's a pretty common usage in the Spring managed world.
>>
>> Thanks for any guidance.
>>
>> --
>> 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] HHH-7610 - Embedded and nulls

[Guillaume Smet]

OK, done: https://github.com/hibernate/hibernate-orm/pull/944 (I just
squashed the commits of Laurent into one)

This PR is for 4.3 as we originally wrote it for 4.3. I already ported it
to 5 but I prefer waiting we have settled everything before submitting the
other PR for 5 (the merge requires a bit of work).

FWIW, we are running this in production for quite some time now.

On Wed, May 6, 2015 at 6:10 PM, Steve Ebersole  wrote:

> Sure, I can take a look at a Pull Request.  Just ping us on the list when
> it is ready (sometimes the PR notifications "get lost" in the shuffle).
>
> On Wed, May 6, 2015 at 9:00 AM, Guillaume Smet 
> wrote:
>
>> Hi all,
>>
>> (sorry for the long silence, have been dealing with personal issues)
>>
>> I have cycles next week and I would like to tackle this issue:
>> https://hibernate.atlassian.net/browse/HHH-7610
>>
>> My colleague, Laurent Almeras, already worked on a patch here:
>>
>> https://github.com/openwide-java/hibernate-orm/commits/embedded-empty-configuration
>> .
>>
>> Steve gave us a few advices and we took them into account in the following
>> commits.
>>
>> Should I rebase the patch and propose a PR? If so, for which branches?
>>
>> As a lot of people asked for it, I would prefer it being integrated
>> instead
>> of keeping a set of patches here at Open Wide.
>>
>> Thanks for your feedback!
>>
>> --
>> 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

[hibernate-dev] Search - Plain text and SimpleQueryParser

[Guillaume Smet]

Hi,

Having some spare time, I revisited my patch that used the Lucene
SimpleQueryParser to provide more advanced search features to the end user.

At my company, our search requirements are usually the following:
- a full text search on the name and description;
- a set of dropdown choices.

Our full text search uses the AND operator as our customers usually
requires this. It's not something we can do with the current keyword()
search (I described the issue at length in
https://hibernate.atlassian.net/browse/HSEARCH-917).

We often give the ability to use boolean operators and phrase queries to
the end user.

How did we expose this feature? We build a Lucene query using the
MultiFieldsQueryParser and we set the default operator to AND. We can't use
the DSL.

Starting with Lucene 4, we have a nice parser which is called
SimpleQueryParser and which is... simple and resilient. And I think it
would be a good idea to expose it via the DSL.

It currently looks like this:
https://github.com/openwide-java/hibernate-search/commit/ee776744760d8115965a05c939227d24133b58ec
(there's not much code, Lucene is doing the magic).

There are a couple of XXX I would like to discuss and I'm not that thrilled
with the names I gave to the options.

I have some spare time this week and next week so I'll be able to polish
the patch based on your feedback!

Have a nice day.

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

Re: [hibernate-dev] Search - Plain text and SimpleQueryParser

[Guillaume Smet]

Hi Sanne,

Thanks for your feedback. My answers below:

On Thu, May 14, 2015 at 11:05 PM, Sanne Grinovero 
wrote:

>  - ignoreAnalyzer() I agree with your comment, it doesn't seem to make
> much sense. But what about not having the method rather than making it
> throw an exception?
> I'm assuming that should be possible by making some changes in the
> interfaces, but I didn't try so I might be missing some complexity.
>
>
Yes, it's not hard at all. I removed the FieldCustomization interface from
PlainTextMatchingContext.


>  - ignoreFieldBridge() This one is more controversial. I think
> generally we should accept the types in their original form, so for
> example accept a parameter which is not a String but a custom user
> type, for which a field bridge or some two-way StringBridge could be
> registered, and we apply the conversion automatically.
> We do this on other APIs and we should be consistent across methods,
> although there are some obscure ambiguities with that choice, for
> example we do apply the FieldBridge from the field *name* and not from
> the runtime type of the parameter, which introduces some complexities
> when the query is targeting multiple fields with different indexing
> options, especially if the input is expected to be in different types.
>

Plain text search only supports String search. It tokenizes and parses the
string to build the query term by term (and terms might be operators,
negative queries, fuzzy queries...). You cannot apply a StringBridge to the
whole string and you cannot apply a StringBridge to each term after the
tokenization.

That's why I'm thinking it's a limitation we should accept.


> I don't think these implications were too clear when we first created
> the DSL, so not ruling out a change of direction to be considered for
> the next major version; you feedback as power user would be essential.
> I still think that it's convenient for example to automatically encode
> a Date type, but the type should then be matched differently to each
> field.. how could we do that using this Lucene parser?
>

Well, it's not how this parser works, that's why I called it text search.

I tighten the DSL a bit in a further commit.

As for the current code, I don't really like the .defaultOperatorIsAnd()
method name. Any better ideas?

Another pain point which your tests are highlighting, is the lack of
> an easy to use, short hand for the sorting API. Created HSEARCH-1872
> as a discussion point.
>

If we're talking about the limitations of the DSL, let's tackle this
subject :).

Here are the main reasons why we are forced to not use the DSL (or at least
add a layer on top of it):
- ability to search on multiple fields with an AND operator: we used the
Lucene MultiFieldsQueryParser, we now have switched to the
SimpleQueryParser (what I propose here would solve this issue)
- ability to ignore a condition if the term (term in a general way) is
null: most of the time, users only define 1 or 2 fields of the search
engine and we want to ignore this part of the query if the term is null.
Currently, we end up with a lot of boilerplate code.
- ability to ignore a query if the query is null (typically a boolean
junction and a for loop with no items)

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

Re: [hibernate-dev] Hibernate Search for Hibernate 5 - status

[Guillaume Smet]

Hi Sanne,

On Sun, May 31, 2015 at 2:47 AM, Sanne Grinovero 
wrote:
>
> I don't think it's acceptable we withhold an Hibernate 5 compatible
> version of Hibernate Search for much longer.
>

FWIW, I'm waiting for this to test Hibernate 5 on our applications and
provide feedback from the field on ORM 5. All our applications are highly
dependent on Search.

So, it would be nice to have an alpha of Search to test all this!

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

[hibernate-dev] ORM 5 - Default schema

[Guillaume Smet]

Hi,

Still trying to get one of our applications starting with ORM 5. With
Search 5.4.0.Beta1 and Spring 4.2.0.RC1, I'm now at the database schema
validation phase.

I think there's something fishy with the way a table is looked for when
we're using specific schemas in our database.

Some background: we use PostgreSQL, we remove the public schema and we
create a schema which is the default schema for the user.

Our Hibernate app doesn't know anything about the schema and it used to
work fine with ORM 3 and 4.

We like this configuration as the schema used is totally transparent for
the application and we can play with it at the database level without
changing the Hibernate configuration.

The fact is that it doesn't work anymore with ORM 5. The problem is that,
when the schema is null, ORM now considers that the schema should be ""
(empty string) if we haven't set a default schema at the JDBC level. This
leads to trying to find the tables in the "" schema which obviously fails.

AFAICS, it's something specifically wanted as in
NormalizingIdentifierHelperImpl.toMetaDataSchemaName, we have the following
lines:
  if ( identifier == null ) {
if ( jdbcEnvironment.getCurrentSchema() == null ) {
return "";
}
identifier = jdbcEnvironment.getCurrentSchema();
}

IMHO, in the null case, if the current schema isn't specified, we should
return null and let the database determine which schema to use instead of
deciding that the schema is "".

If it's null, the schema filter will not be considered and the schema
resolution will be let to the database.

Any thoughts?

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

Re: [hibernate-dev] ORM 5 - Default schema

[Guillaume Smet]

FWIW, if I change the return ""; to return null;, I get my application to
start \o/.

I'll start testing the application more in depth.

FWIW, I don't know if it's something normal but
AvailableSettings.DEFAULT_SCHEMA is not used in the constructor of
JdbcEnvironmentImpl used when JDBC is available (I first tried to fix the
issue by using this setting).

On Tue, Jun 16, 2015 at 12:24 PM, Guillaume Smet 
wrote:

> Hi,
>
> Still trying to get one of our applications starting with ORM 5. With
> Search 5.4.0.Beta1 and Spring 4.2.0.RC1, I'm now at the database schema
> validation phase.
>
> I think there's something fishy with the way a table is looked for when
> we're using specific schemas in our database.
>
> Some background: we use PostgreSQL, we remove the public schema and we
> create a schema which is the default schema for the user.
>
> Our Hibernate app doesn't know anything about the schema and it used to
> work fine with ORM 3 and 4.
>
> We like this configuration as the schema used is totally transparent for
> the application and we can play with it at the database level without
> changing the Hibernate configuration.
>
> The fact is that it doesn't work anymore with ORM 5. The problem is that,
> when the schema is null, ORM now considers that the schema should be ""
> (empty string) if we haven't set a default schema at the JDBC level. This
> leads to trying to find the tables in the "" schema which obviously fails.
>
> AFAICS, it's something specifically wanted as in
> NormalizingIdentifierHelperImpl.toMetaDataSchemaName, we have the following
> lines:
>   if ( identifier == null ) {
> if ( jdbcEnvironment.getCurrentSchema() == null ) {
> return "";
> }
> identifier = jdbcEnvironment.getCurrentSchema();
> }
>
> IMHO, in the null case, if the current schema isn't specified, we should
> return null and let the database determine which schema to use instead of
> deciding that the schema is "".
>
> If it's null, the schema filter will not be considered and the schema
> resolution will be let to the database.
>
> Any thoughts?
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Hibernate Search] DocValues and Sorting API -> new mapping annotations ?

[Guillaume Smet]

Hi Sanne,

On Wed, Jul 29, 2015 at 1:26 PM, Sanne Grinovero 
wrote:

> I'm not sure if this should be extending the @Field annotation as
> there are special restrictions implied in terms of analysis: are we
> going to enforce a specific type of tokenizer, or simply take the
> analysis option away?
>

You can't remove the analysis option away: it's often used to normalize
sorting on strings (lowercase, remove accents, remove special characters
and so on).

FWIW, we use specific fields for sorting each time we need to sort on a
string as we don't want to tokenize the string (but not for numerics and
dates). Maybe @SortFields/@SortField annotations would be in order (I don't
like Sortable as I don't think it's a good idea to use these fields for
search).

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

Re: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed interceptor

[Guillaume Smet]

Hi Steve,

On Thu, May 7, 2015 at 5:37 PM, Guillaume Smet 
wrote:

>
> Yup, EntityManagerFactoryBuilderImpl.populate(SessionFactoryBuilder,
> StandardServiceRegistry) was my favorite spot too but it's currently
> private. Would you mind making it protected?
>

Working on my backlog for ORM 5 migration and looks like we missed this
one. Any chance it could be integrated in the next 5.x release?

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

Re: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed interceptor

[Guillaume Smet]

Nothing yet. Wanted to be sure you weren't against the principle of making
this method protected.

If you agree with this plan, I'll do the legwork.

On Wed, Aug 26, 2015 at 3:34 PM, Steve Ebersole  wrote:

> Is there a Jira?  PR?
>
> On Wed, Aug 26, 2015, 8:12 AM Guillaume Smet 
> wrote:
>
>> Hi Steve,
>>
>> On Thu, May 7, 2015 at 5:37 PM, Guillaume Smet 
>> wrote:
>>
>>>
>>> Yup, EntityManagerFactoryBuilderImpl.populate(SessionFactoryBuilder,
>>> StandardServiceRegistry) was my favorite spot too but it's currently
>>> private. Would you mind making it protected?
>>>
>>
>> Working on my backlog for ORM 5 migration and looks like we missed this
>> one. Any chance it could be integrated in the next 5.x release?
>>
>> Thanks!
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Testing Hibernate 5: injecting a Spring managed interceptor

[Guillaume Smet]

Done: https://hibernate.atlassian.net/browse/HHH-10059

On Wed, Aug 26, 2015 at 4:23 PM, Steve Ebersole  wrote:

> It's fine
>
> On Wed, Aug 26, 2015, 8:54 AM Guillaume Smet 
> wrote:
>
>> Nothing yet. Wanted to be sure you weren't against the principle of
>> making this method protected.
>>
>> If you agree with this plan, I'll do the legwork.
>>
>> On Wed, Aug 26, 2015 at 3:34 PM, Steve Ebersole 
>> wrote:
>>
>>> Is there a Jira?  PR?
>>>
>>> On Wed, Aug 26, 2015, 8:12 AM Guillaume Smet 
>>> wrote:
>>>
>>>> Hi Steve,
>>>>
>>>> On Thu, May 7, 2015 at 5:37 PM, Guillaume Smet <
>>>> guillaume.s...@gmail.com> wrote:
>>>>
>>>>>
>>>>> Yup, EntityManagerFactoryBuilderImpl.populate(SessionFactoryBuilder,
>>>>> StandardServiceRegistry) was my favorite spot too but it's currently
>>>>> private. Would you mind making it protected?
>>>>>
>>>>
>>>> Working on my backlog for ORM 5 migration and looks like we missed this
>>>> one. Any chance it could be integrated in the next 5.x release?
>>>>
>>>> Thanks!
>>>>
>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] ORM5 and naming strategies (or get me my foreign keys back!)

[Guillaume Smet]

Hi all,

(starting with kudos to Steve for the 5 release, it's the first problem I
find in my migration journey)

I'm currently working on porting 2 of our existing applications to ORM 5 (I
already ported our template application to start new projects).

The naming strategies are giving me a hard time: we used the
DefaultComponentSafeNamingStrategy before and there is no real equivalent
in ORM 5.

It wouldn't be a problem to port it but there are other problems which are
not directly related. For instance, the foreign keys used to be named
fk_ and they are now named fk:
"fk421dhylghv6secx82frew7luc" FOREIGN KEY (action_id) REFERENCES
auditaction(id)
"fk_26d86etoechksvjt5xmjdbqqg" FOREIGN KEY (action_id) REFERENCES
auditaction(id)

Same for the unique keys EXCEPT for the natural ids which are still named
the old way (with a uk_ prefix):
"uk_idim50mwro7eanb1gn9p4xv01" UNIQUE CONSTRAINT, btree (unixname)
(see AnnotationBinder line 2274)

AFAICS, there's no easy way to migrate an existing application to ORM 5 if
we want to let ORM update the schema. We end up with duplicated foreign
keys/constraints.

So a few questions:
* Am I the only one who sees this as a problem?
* Shouldn't we propose naming strategies allowing a smoother transition
from ORM 4 to 5?
* Should we add more prominent warnings in the migration doc?
* Should the prefix naming be consistent (e.g. with or without an
underscore)? I personally like it better with the underscore.

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

Re: [hibernate-dev] ORM5 and naming strategies (or get me my foreign keys back!)

[Guillaume Smet]

Hi Steve,

On Tue, Sep 15, 2015 at 6:49 PM, Steve Ebersole  wrote:

> The naming strategies are giving me a hard time: we used the
>> DefaultComponentSafeNamingStrategy before and there is no real equivalent
>> in ORM 5.
>>
>
> org.hibernate.boot.model.naming.ImplicitNamingStrategyComponentPathImpl is
> the corolary.  These may or may not migrate directly due to the *split*.
> The old NamingStrategy actually covered implicit naming, physical naming
> and logical naming; whereas we have now split these out into distinct
> contracts (well for implicit and physical anyway; it was never a good idea
> to expose logical naming as a pluggable contract).
>

Not exactly. It inherits from JpaCompliant strategy whereas
DefaultComponentSafeNamingStrategy
inherits from EJB3NamingStrategy.

So if you used DefaultComponentSafeNamingStrategy, you need to have
something like ImplicitNamingStrategyComponentPathImpl but inheriting from
LegacyJpa.

That's what I did. Maybe we should include it to provide an easier upgrade
path?

It wouldn't be a problem to port it but there are other problems which are
>> not directly related. For instance, the foreign keys used to be named
>> fk_ and they are now named fk:
>> "fk421dhylghv6secx82frew7luc" FOREIGN KEY (action_id) REFERENCES
>> auditaction(id)
>> "fk_26d86etoechksvjt5xmjdbqqg" FOREIGN KEY (action_id) REFERENCES
>> auditaction(id)
>>
>> Same for the unique keys EXCEPT for the natural ids which are still named
>> the old way (with a uk_ prefix):
>> "uk_idim50mwro7eanb1gn9p4xv01" UNIQUE CONSTRAINT, btree (unixname)
>> (see AnnotationBinder line 2274)
>>
>> AFAICS, there's no easy way to migrate an existing application to ORM 5 if
>> we want to let ORM update the schema. We end up with duplicated foreign
>> keys/constraints.
>>
>
> Well the bottom line is that schema tooling was never a supported feature
> prior to 5.0.  We "supported" schema creation and dropping as so far as it
> was needed for supporting the JPA feature.  But migration and validation
> never considered supported prior to 5.0
>
> I know people liked to use these features as if they were supported, but
> they weren't.
>

Yes I know but I think we should provide more guidance and put prominent
warnings for people using it.


> * Shouldn't we propose naming strategies allowing a smoother transition
>> from ORM 4 to 5?
>>
>
> So propose... :)
>

I thought about it and I think it's better to break things in a major
version upgrade rather than having one more legacy naming strategy. We
already have too many of them.


> * Should we add more prominent warnings in the migration doc?
>>
>
> Such as ...?
>

I was thinking of something like:
"""
The following table provide guidance on how to migrate your existing
configuration:

Old naming strategy || Physical naming strategy || Logical naming strategy
(with sensible values)

Note that if you set the hbmddl setting to update (which was never
officially supported until ORM 5.x), you need to be extra careful in your
migration because the names of database objects (foreign keys, unique keys)
generated by ORM 5.x might be different from the names generated by ORM
4.x. You might need to clean up your existing databases from the duplicated
objects.
"""

WDYT?

* Should the prefix naming be consistent (e.g. with or without an
>> underscore)? I personally like it better with the underscore.
>>
>
>
> Really it is a practical point.  Some databases limit object name length.
> An underscore takes up one (arguably unnecessary) character position.  I
> guess it is conceivable that we add the underscore in the
> ImplicitNamingStrategy and then conditionally remove it in the
> PhysicalNamingStrategy.
>

After thinking about it, it's better if we break the conventions for the
constraint names: it's easier to find the old ones to drop them!

But, I think we should be consistent between foreign keys and unique keys.
Currently, the prefix for foreign keys if "FK" and the prefix for unique
keys "UK_" with an underscore.

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

[hibernate-dev] A few questions about Search 5.5.0

[Guillaume Smet]

Hi,

I upgraded our framework to 5.5.0 and I have a few questions about it.

==
First, I had to remove the existing indexes otherwise I had exceptions
about version of the index. Is this expected? As far as I remember, it's
been a long time since we had to remove the indexes after an upgrade.

Caused by: org.apache.lucene.index.IndexFormatTooOldException: Format
version is not supported (resource
BufferedChecksumIndexInput(MMapIndexInput(path="/data/services/test/data/helios/lucene/fr.openwide.helios.core.business.ticket.model.MessageFile/segments_1"))):
-11 (needs to be between 1071082519 and 1071082519). This version of
Lucene only supports indexes created with release 4.0 and later.

Maybe it should be integrated in the blog post that one might need to
clean up indexes if they come from before the switch to Lucene 4?


==
Second, I have warnings like that in my logs:
HSEARCH000289: Requested sort field(s) company.nameSort, nameSort are not
configured for entity type
fr.openwide.helios.core.business.contract.model.HeliosContract mapped to
index fr.openwide.helios.core.business.contract.model.HeliosContract, thus
an uninverting reader must be created. You should declare the missing sort
fields using @SortField.

Shouldn't it be @Sort*able*Field?

==
And finally, since recently, it's necessary to sort dates using
SortField.Type.LONG instead of SortField.Type.STRING. I haven't found this
information in the blog posts of any releases. Or did I miss something?

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

Re: [hibernate-dev] A few questions about Search 5.5.0

[Guillaume Smet]

Hi Sanne,

On Sat, Sep 19, 2015 at 11:29 PM, Sanne Grinovero 
wrote:

> But: AFAIR pre-4 support was entirely dropped, this additional
> dependency is only useful for indexes created between 4.0 to 5.0. You
> never fully rebuilt the indexes since Lucene 3.x?
>

Probably not - we haven't changed the indexation rules for a while. Lucene
4 support was not added that long ago in Search IIRC.


> Sorry for not mentioning this in the migration guide, I forgot but
> also I do generally assume that people will need to reindex anyway for
> various other reasons.
>

Yeah, the thing is you really need to completely drop the old indexes
before even starting your application (we have a console with various admin
features from where we can launch a reindex).

FWIW, I put into production this morning 2 applications using ORM 5 and
Search 5.5. Hope to migrate more of them in the next few months.

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

[hibernate-dev] [Search] Something fishy with sort by id

[Guillaume Smet]

Hi,

After the upgrade to Search 5.5 (I think we skipped 5.4 on this app), I
have a weird behavior when I sort by id.

My id is a Long just indexed with @DocumentId:
@Id
@DocumentId
private Long id;

and my sort is defined like this:
fullTextQuery.setSort(new Sort(new SortField("id", SortField.Type.LONG,
true)));

Everything was reindexed.

It used to work before. Is this something expected?

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

Re: [hibernate-dev] [Search] Something fishy with sort by id

[Guillaume Smet]

On Wed, Sep 23, 2015 at 10:59 PM, Gunnar Morling 
wrote:

> What is the exact behaviour you observe?
>

Oh, yeah, forgot the most important :).

The results are completely unsorted. It should be sorted by id desc and I
have:
26687
26941
27034
27244
27235
28414
28327
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Something fishy with sort by id

[Guillaume Smet]

And the sort is different after each reindex.

On Wed, Sep 23, 2015 at 11:05 PM, Guillaume Smet 
wrote:

> On Wed, Sep 23, 2015 at 10:59 PM, Gunnar Morling 
> wrote:
>
>> What is the exact behaviour you observe?
>>
>
> Oh, yeah, forgot the most important :).
>
> The results are completely unsorted. It should be sorted by id desc and I
> have:
> 26687
> 26941
> 27034
> 27244
> 27235
> 28414
> 28327
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Something fishy with sort by id

[Guillaume Smet]

And if I sort by creationDate desc, the sort is OK. So I really think
there's something related to sorting on the id.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Something fishy with sort by id

[Guillaume Smet]

Hi Hardy,

On Thu, Sep 24, 2015 at 10:47 AM, Hardy Ferentschik 
wrote:

> Ok, still it makes modifications on the actual document id field, which
> should be avoided for the mentioned reasons.


OK. I must admit that as it worked well before, we didn't think a lot about
using the @DocumentId field for sorting :).

I'll go clean up our applications!

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

Re: [hibernate-dev] Lucene 5.4 available: include it in a micro release?

[Guillaume Smet]

Hi Sanne,

I'm not that thrilled about it. We have at least 2 blocking bugs to fix in
5.5.2 and if there is a regression in Lucene 5.4 for one reason or another,
we won't be able to upgrade to 5.5.2.

Would prefer it to go in a 5.6 release.

-- 
Guillaume

On Wed, Dec 16, 2015 at 2:22 PM, Sanne Grinovero 
wrote:

> Hello all,
>
> Apache Lucene 5.4.0 is released as stable, and while it includes
> several benefits - not least a performance fix from myself which I'd
> be keen to take advantage of - there are no significant changes
> visible to end users, expect I think this one is worth a warning:
>
>  LUCENE-6590: Query.setBoost(), Query.getBoost() and Query.clone() are
> gone. In order to apply boosts, you now need to wrap queries in a
> BoostQuery.
>
> Although, it doesn't affect any of our code not examples so a release
> note might be acceptable.
>
> There are several other interesting performance improvements.
> So I'm tempted to upgrade to this version in the next maintenance
> (micro) release of Hibernate Search 5.5.
>
> What do you all think about that?
>
> 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] 5.1 tentative release date

[Guillaume Smet]

Hi Steve and al.

Any chance we could make progress on HHH-7610
 and
https://github.com/hibernate/hibernate-orm/pull/1080 for 5.1?

I'll revisit the PR tomorrow to fix the conflicts.

-- 
Guillaume

On Tue, Jan 12, 2016 at 5:08 PM, Scott Marlow  wrote:

>
>
> On 01/11/2016 11:04 AM, Steve Ebersole wrote:
> > On Fri, Jan 8, 2016 at 9:00 PM Scott Marlow  > > wrote:
> >
> > Should we also look at changing Hibernate to not require Javassist
> > classes be on the deployment classpath?
> >
> >
> > I just don't see how that is ever going to be realistically possible.
> > If you have specific suggestions, we are all ears ;)
>
> I'm thinking that we should defer the Javassist upgrade until we figure
> out what we want to do exactly to address this problem.  I would expect
> that other modular classloading environments besides WildFly may also
> need a fix.
>
> For a possible workaround (for proxies), if we were able to clone the
> needed Javassist runtime classes, into the application classloader and
> generate proxies that use the cloned copies, I think that could help.
> We would have to clone them into a private package name (e.g. something
> like org.hibernate.javassist.runtime.*).  We would also have to generate
> the proxies using the cloned classes.
>
> There may be other ways to change Hibernate applications to not depend
> on the Javassist runtime classes.  For example if we change the bytecode
> that we generate, to not reference the Javassist runtime classes, that
> also would address this.
> ___
> 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] 5.1 tentative release date

[Guillaume Smet]

On Tue, Jan 12, 2016 at 6:40 PM, Steve Ebersole  wrote:

> If you clean up the conflicts I can look for 5.1
>

Done!

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

[hibernate-dev] [Search] Travis support

[Guillaume Smet]

Hi,

As mentioned in our last discussion, I explored adding Travis support to
Search.

The diff is here:
https://github.com/gsmet/hibernate-search/commit/cbd2c1fff05532974823da572795d53cb8b9d26a
(yes it's short but it was a long road :))

I had to raise a bit the JGroups timeout for one test and had to fix
TestRunnerStandalone
so that it effectively uses the configuration from the profile (this change
is not specific to Travis and should be committed anyway).

The result is here:
https://travis-ci.org/gsmet/hibernate-search

What I like in Travis:
- The CI configuration is code and is versioned
- Parallelization with a *lot* of resources
- The ability to build a test matrix very easily
- Complete isolation as each build is run in its own Docker container

What is less cool:
- The only way to get the logs is to ship them to AWS S3 - that said, I did
it and it's pretty straightforward as it's well integrated (I commented out
the code in the .travis.yml for now)
- It might seem less flexible as we are depending on the Travis
infrastructure (for instance, I created a ticket to ask for the support of
JDK 9: https://github.com/travis-ci/travis-ci/issues/5520) but in fact, you
can do whatever you want: see https://github.com/Blazebit/blaze-persistence
.travis.yml file for a comprehensive example

So if we move to Travis, I think the regular builds could run on Travis and
we could keep Jenkins for specific ones (deploy/release).

I'll take a look at OGM tomorrow. Travis supports out of the box most of
the NoSQL databases (https://docs.travis-ci.com/user/database-setup/) so
I'm pretty curious to see how it goes.

Thoughts?

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

Re: [hibernate-dev] [Search] Travis support

[Guillaume Smet]

Yep: https://travis-ci.org/gsmet/hibernate-search

As already mentioned, if you want to get the results of the test, you can
push them to an AWS S3 bucket.

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

[hibernate-dev] [Search] ElasticSearch - DSL

[Guillaume Smet]

Hi all (and especially Gunnar),

I dug a bit in your ElasticSearch work today as I wanted to give a try to
the facet implementation and I was wondering if maybe we should use the
ElasticSearch DSL to build the queries instead of building raw JSON strings.

I experimented here:
https://github.com/gsmet/hibernate-search/commit/18737f720a1200b125adf2bb0465b52d5d2b3ca3

I think the code is a bit clearer now. I haven't changed all the queries in
the tests so I kept the fromJson method in ElasticSearchQueries but I think
we should remove it and rely on the DSL: I'll wait for your opinion as you
might have had a very good reason to not use the DSL.

One of the challenges waiting for us will be to transform the Lucene
Filters into proper Elastic Search queries.

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

Re: [hibernate-dev] [Search] Travis support

[Guillaume Smet]

Hi Sanne,

On Thu, Jan 28, 2016 at 3:23 PM, Sanne Grinovero 
wrote:

> I am a bit skeptical as we have CI working already on ci.hibernate.org
> and having limited people we can't really afford to fix things which
> already work.
>

I perfectly understand that. I wanted to experiment it without bothering
you about it.


> To summarize what I like of Travis:
>  - simple configuration
>  - not much maintenance from our side
>  - your recommendation counts
>  - they pay the bills?
>  - you say that it's very popular among Java developers.
>
> About the popularity point, you surprised me. I honestly thought that
> we should stay on Jenkins because that was the most popular one. Do
> you have some data to back that nowadays people are more familiar with
> Travis?
>

It's very widespread in the Open Source projects running on GitHub, either
in Java, Ruby, PHP, Python and so on.

HikariCP for instance uses Travis and there are a lot of others projects
using it: https://github.com/brettwooldridge/HikariCP .

We use Jenkins at my company too for our private projects but we use Travis
for our Open Source ones.


> Finally I have been burned several times by not having "root access"
> on the whole thing. I guess Docker might make this reasoning moot now,
> but it's something to consider.
> It's also quite important that we make sure our releases are created
> in a reliable environment, so there's the trust issue of delegating
> the keys to the kingdom to a third party. I'd even like it we could
> start "signing" the artifacts we release as some users mentioned that
> this would be important for them.
>

Yes, Travis won't replace the release tasks. I think it's good for the day
to day builds and PR builds and we should only use it for that - if we
decide to use it.


> Sorry to be skeptical, I didn't mean to stress the negative aspects
> but to clarify that there are many aspects to consider for such a
> move.
> I'm definitely open to consider using it for a subset of jobs, like
> you mentioned the PR review system might be a good fit.
> It's also a good thing for sure to test in additional environments:
> can it also run jobs on Windows and OSX ? We're missing that.. we
> could fix the lack of Windows via AWS but that has a steep price tag..
> I'll rather volunteer an old laptop from home.
>

They have OSX support but it's sparse. It's mostly here to test MacOS and
iOS apps. They don't have Windows support.

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

Re: [hibernate-dev] [Search] ElasticSearch - DSL

[Guillaume Smet]

Hey Gunnar,

On Thu, Jan 28, 2016 at 6:52 PM, Gunnar Morling 
wrote:
>
> They in turn pull in Lucene in a version which potentially differs
> from the Lucene version used by Hibernate Search itself. Also I wanted
> to leave the door open for supporting multiple (potentially
> incompatibly altered) versions of ES backends, say ES 2 and a future
> ES 3.
>
> All in all, these advantages outweigh the slightly simpler usage of
> the DSL to me.


Yeah, I understand your concerns. Apart from the more complicated usage,
I'm afraid building raw JSON is going to be harder to maintain. We only do
simple things atm and I don't find the JSON manipulation very readable nor
very solid. It's going to be worse when we will add aggregations for
faceting and so on.

As for the dependencies, I could take a look at shading the necessary
classes for the builders and see if we can come up with something clean? I
don't know if it's something acceptable for an Hibernate project.

It doesn't solve the multi versions thingy but if they change the API, it's
going to be quite ugly to generate different JSON queries anyway, don't you
think?


> > One of the challenges waiting for us will be to transform the Lucene
> > Filters into proper Elastic Search queries
>
> I haven't looked into filters yet, but it's high on my agenda.
>
> Do you think it's more difficult than transforming actual queries?
> Btw. the ES PoC allows to pass in plain ES queries, at some point
> these should be allowed to contain filter clauses, too (this might
> even work already, haven't tried it).
>

Yeah I saw you could inject native ES queries and that's also something
that worries me with the raw JSON approach. I find it much more
user-friendly to provide an API to build the queries.

(Using these various discussions to adjust how I work and be more compliant
with the Hibernate way of life :))

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

[hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded

[Guillaume Smet]

Hi,

While playing with ElasticSearch faceting (and having tests failing due to
that), I noticed that for Longs and Dates, the preexisting range faceting
doesn't take into account facetRequest.hasZeroCountsIncluded().

See
https://github.com/hibernate/hibernate-search/blob/master/engine/src/main/java/org/hibernate/search/query/engine/impl/QueryHits.java#L308
and a few lines below for floating point ranges which take into account
this very parameter.

Is this something expected? Should I prepare a PR to fix it?

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

Re: [hibernate-dev] [Search] Travis support

[Guillaume Smet]

Hi,

FWIW, I also added Travis support to OGM (mostly to see if we could do it
easily with all the NoSQL databases supported) here:
https://travis-ci.org/gsmet/hibernate-ogm/
https://github.com/gsmet/hibernate-ogm/blob/travis-support/.travis.yml

What I also find interesting in Travis is that you can easily enable CI for
your own fork once the .travis.yml is committed to the main repository.

-- 
Guillaume

On Thu, Jan 28, 2016 at 6:26 PM, Guillaume Smet 
wrote:

> Hi Sanne,
>
> On Thu, Jan 28, 2016 at 3:23 PM, Sanne Grinovero 
> wrote:
>
>> I am a bit skeptical as we have CI working already on ci.hibernate.org
>> and having limited people we can't really afford to fix things which
>> already work.
>>
>
> I perfectly understand that. I wanted to experiment it without bothering
> you about it.
>
>
>> To summarize what I like of Travis:
>>  - simple configuration
>>  - not much maintenance from our side
>>  - your recommendation counts
>>  - they pay the bills?
>>  - you say that it's very popular among Java developers.
>>
>> About the popularity point, you surprised me. I honestly thought that
>> we should stay on Jenkins because that was the most popular one. Do
>> you have some data to back that nowadays people are more familiar with
>> Travis?
>>
>
> It's very widespread in the Open Source projects running on GitHub, either
> in Java, Ruby, PHP, Python and so on.
>
> HikariCP for instance uses Travis and there are a lot of others projects
> using it: https://github.com/brettwooldridge/HikariCP .
>
> We use Jenkins at my company too for our private projects but we use
> Travis for our Open Source ones.
>
>
>> Finally I have been burned several times by not having "root access"
>> on the whole thing. I guess Docker might make this reasoning moot now,
>> but it's something to consider.
>> It's also quite important that we make sure our releases are created
>> in a reliable environment, so there's the trust issue of delegating
>> the keys to the kingdom to a third party. I'd even like it we could
>> start "signing" the artifacts we release as some users mentioned that
>> this would be important for them.
>>
>
> Yes, Travis won't replace the release tasks. I think it's good for the day
> to day builds and PR builds and we should only use it for that - if we
> decide to use it.
>
>
>> Sorry to be skeptical, I didn't mean to stress the negative aspects
>> but to clarify that there are many aspects to consider for such a
>> move.
>> I'm definitely open to consider using it for a subset of jobs, like
>> you mentioned the PR review system might be a good fit.
>> It's also a good thing for sure to test in additional environments:
>> can it also run jobs on Windows and OSX ? We're missing that.. we
>> could fix the lack of Windows via AWS but that has a steep price tag..
>> I'll rather volunteer an old laptop from home.
>>
>
> They have OSX support but it's sparse. It's mostly here to test MacOS and
> iOS apps. They don't have Windows support.
>
> --
> Guillaume
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded

[Guillaume Smet]

On Wed, Feb 3, 2016 at 11:45 AM, Hardy Ferentschik 
wrote:

> Sounds like an oversight. I would add it, make sure tests still pass and
> add some new ones ;-)
>

Will do.

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

Re: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded

[Guillaume Smet]

On Wed, Feb 3, 2016 at 12:13 PM, Sanne Grinovero 
wrote:

> Good catch!
> Make sure to open a JIRA issue as first step, to not forget about this
> even in case you get distracted.
>

I'm in the process of opening it :).
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search] Range faceting for Longs and Dates not taking into account hasZeroCountsIncluded

[Guillaume Smet]

On Wed, Feb 3, 2016 at 9:32 AM, Gunnar Morling  wrote:

> Guillaume, just in case, if you plan to work on stuff around the ES
> backend, I'd recommend you do so based on my pending PR
> https://github.com/hibernate/hibernate-search/pull/960. This changes
> quit a bit, so you may be in merge hell otherwise.
>

Yes, I have seen it and I have based my work on it!

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

[hibernate-dev] [Search] ElasticSearch - Progress on faceting

[Guillaume Smet]

Hi,

So the good news: most of the faceting tests now pass with ES.

I rebased the patch onto master.

https://github.com/gsmet/hibernate-search/commits/elastic-facet2
and for now only one commit:
https://github.com/gsmet/hibernate-search/commit/657ecfe684e6b4e952d11274523a4c5683e0c7eb

It's not a PR yet as it's not feature complete and there are still (a few)
tests failing.

General infrastructure


- I introduced a JsonBuilder to make the gson API chainable: I think it's
more readable this way. I haven't updated everything to use it (especially
the Lucene Query -> Json part is not ported yet). Should I continue with
it? Please, please, say yes :).
- All the API is now based on JsonObject so you don't have to play with
String -> Json -> String -> Json manipulation
---> would appreciate feedback on these 2 changes so that I can make
everything consistent
- I introduced a ToElasticSearch class which translates Lucene/HSearch
objects to Json. I moved the existing query translator there.
- I'm not sure building the exact same document we build for Lucene is the
way to go. I'm wondering if we should have a distinct document builder for
ES. I'll see how it works for facets not being fields.
- I made a few fixes here and there: especially the indexing didn't support
multiple values per field. I made something complicated, maybe we could
just index a JsonArray even for single values? see
https://github.com/gsmet/hibernate-search/commit/cb88b5790996442e137fab4aec330be04dfef587#diff-e832854d983fba756218944587fd5c57R234

Faceting
===

- The querying/extraction should be OK
- ES doesn't support range bounds inclusion/exclusion for range faceting so
I used the query faceting to build the range faceting
- I have to work on the mapping as having multiple facets on the same field
is not supported yet: currently I use the indexed field to build the
facets, not specific fields
- I have some additional work to do on indexing related to the above matter

Various issues
===

- A few tests don't pass:
. ElasticSearch returns facets results even if the field doesn't exist: not
sure we can do anything about that
. A test in the WebShopTest is failing as I don't support yet faceting
based on a non existing field
. CollectionUpdateEventTest is failing: this one is weird
- I had to work around an issue with the EsDateBridge and faceting (marked
as XXX in DocumentBuilderIndexedEntity): Dates are considered to be Long
and for ES, we want them to be Strings. Would appreciate a comment on that.

Comments and thoughts appreciated.

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

Re: [hibernate-dev] [Search] ElasticSearch - Progress on faceting

[Guillaume Smet]

Hi Gunnar,

On Thu, Feb 4, 2016 at 7:01 PM, Gunnar Morling  wrote:

> > - I introduced a JsonBuilder to make the gson API chainable: I think it's
> > more readable this way. I haven't updated everything to use it
> (especially
> > the Lucene Query -> Json part is not ported yet). Should I continue with
> > it? Please, please, say yes :).
>
> It's a great example of how subjective readability is, because I don't
> find it necessarily better than the previous version, it's just
> different :) An actual disadvantage is the higher number of object
> allocations due to the builders.
>
> In the end I don't really care about it that much; how the JSON is
> created is more a technical detail which we may change at any time. So
> if you feel strongly about it, feel free to do it. But I would not
> expose this builder and the usage of GSON through the public API so we
> actually have the freedom of future changes.
>

Maybe readability wasn't the best term. "Writeability" is better as what I
really like about it is the capacity to write the code as I would write the
JSON instead of writing it in the reverse way when I have to nest objects.


> > - I introduced a ToElasticSearch class which translates Lucene/HSearch
> > objects to Json. I moved the existing query translator there.
> > - I'm not sure building the exact same document we build for Lucene is
> the
> > way to go. I'm wondering if we should have a distinct document builder
> for
> > ES. I'll see how it works for facets not being fields.
>
> Yes, keep in mind that the route through creating a Lucene Document
> object is just temporary hack to have a PoC of integrating ES. For HS
> 6 we'll look into refactoring the required pieces and avoid that
> intermediary step. Not sure how much sense it makes to spend cycles on
> this right now, it'll be larger task for sure.
>

OK. We're on the same page.

I think we won't be able to support the WebShopTest without reworking that.
We have this:
@Facets({
@Facet(name = "cubicCapacity", forField = "cubicCapacity",
encoding = FacetEncodingType.STRING),
@Facet(name = "cubicCapacity_Numeric", forField =
"cubicCapacity", encoding = FacetEncodingType.LONG)
})
The original Lucene document would probably allow to do something about it
but we lose a lot of information due to the call to doc =
facetConfig.build( doc ) which applies the Lucene facet magic, removes
interesting information and adds less qualified information.


> > - I had to work around an issue with the EsDateBridge and faceting
> (marked
> > as XXX in DocumentBuilderIndexedEntity): Dates are considered to be Long
> > and for ES, we want them to be Strings. Would appreciate a comment on
> that.
>
> Couldn't you do the conversion in the ElasticSearchIndexWorkVisitor?
>

Not really. The preexisting code was failing with a class cast exception.
That's why I had to fix it this way. I think the indexing type (STRING,
LONG) should be determined per backend instead of being global.

Should we create a JIRA issue to centralize all the API challenges related
to ES for 6?

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

[hibernate-dev] Naming strategies and join tables

[Guillaume Smet]

Hi,

I'm migrating another application to 5.x and have the following issue with
the new naming strategies.

We used EJB3NamingStrategy and are now using
ImplicitNamingStrategy*Legacy*JpaImpl which is advertised as being its
replacement.

The model is the following:
@Entity
AbstractProjet
   > @Entity
  @DiscriminatorValue(value = "ProjetDiffusion")
   public class ProjetDiffusion extends AbstractProjet {
 @ElementCollection
 @Enumerated(EnumType.STRING)
 @JoinTable(uniqueConstraints = {
@UniqueConstraint(columnNames = { "projetdiffusion_id", "technologies" }) })
 private List technologies =
Lists.newArrayList();

Before the upgrade to 5, the join table was called
projetdiffusion_technologies and the column was projetdiffusion_id.

After the upgrade to 5, the join table is called
abstractprojet_technologies and the column abstractprojet_id. Thus, we have
an error on the creation of the unique constraint.

Is this change expected?

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

Re: [hibernate-dev] Naming strategies and join tables

[Guillaume Smet]

Important point: AbstractProjet uses SINGLE_TABLE inheritance.

On Mon, Feb 22, 2016 at 12:10 PM, Guillaume Smet 
wrote:

> Hi,
>
> I'm migrating another application to 5.x and have the following issue with
> the new naming strategies.
>
> We used EJB3NamingStrategy and are now using
> ImplicitNamingStrategy*Legacy*JpaImpl which is advertised as being its
> replacement.
>
> The model is the following:
> @Entity
> AbstractProjet
>> @Entity
>   @DiscriminatorValue(value = "ProjetDiffusion")
>public class ProjetDiffusion extends AbstractProjet {
>  @ElementCollection
>  @Enumerated(EnumType.STRING)
>  @JoinTable(uniqueConstraints = {
> @UniqueConstraint(columnNames = { "projetdiffusion_id", "technologies" }) })
>  private List technologies =
> Lists.newArrayList();
>
> Before the upgrade to 5, the join table was called
> projetdiffusion_technologies and the column was projetdiffusion_id.
>
> After the upgrade to 5, the join table is called
> abstractprojet_technologies and the column abstractprojet_id. Thus, we have
> an error on the creation of the unique constraint.
>
> Is this change expected?
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HSEARCH-1917, faceting, indexNullAs, FieldBridges

[Guillaume Smet]

Hi,

While looking at HSEARCH-1917 which is an issue with faceting and null
values, I came up with the following observations:
1/ Faceting doesn't take into account indexNullAs
2/ Faceting doesn't take into account FieldBridges

1/

In HSEARCH-1917, Hardy talked about supporting indexNullAs.

Does it make sense for everyone?

I don't have a strong opinion about it and if we answer no to 2/ for the
time being, maybe it's better to not support it for now (but I would fix
the faceting on null values anyway).

2/

FieldBridges are also not supported by faceting. In the case of a
TwoWayFieldBridge, we could consider applying the FieldBridge to the values
before storing them in the facet field.

One thing that made me think about it is that, currently, with the
Elasticsearch backend, facet values are created from the indexed field so
they take into account the FieldBridge.

Well, apart if it's a facet which has a name different from the field. Then
the facet values are extracted from the facet values created in the Lucene
document. In this case, the behavior is similar to the Lucene backend
behavior.

My current opinion is that we should for now fix HSEARCH-1917 by adding a
if (value == null) return; at the top of addFacetDocValues and revisit the
2 subjects later for 6.

Anyone against me creating an issue to centralize all the things we need to
fix in FieldBridges/Document building for 6? I would rather create a single
issue for now so that we keep an overview of all we need to fix before
defining exactly what we want to do.

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

Re: [hibernate-dev] HSEARCH-1917, faceting, indexNullAs, FieldBridges

[Guillaume Smet]

On Tue, Feb 23, 2016 at 7:21 PM, Sanne Grinovero 
wrote:

> I don't have a strong opinion on the usefulness on faceting on null;
> would someone have a sensible example of faceting on a "null value" ?
>
> We can fix it but I have the impression it's just about fixing a
> developer's itch because of it being inconsistent with other
> components; if it helps with Elasticsearch integration then that makes
> more sense to me.
>

It's not faceting on a null value, it's the ability to support null values
in faceted fields when indexing the entity. Currently, it throws a NPE on
indexing. For instance, you might have entities which doesn't have a value
for a given faceted field.

Does it make more sense?


> But why would you fix it by "if (value == null) return;" ? Do you
> think you can make it work with that? I'd rather actually index the
> marker token defined by 'indexNullAs'.
>

Do you think we would want facet results for the indexNullAs value?


> +1 to collect notes on FieldBridge and Document change wishes.


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

[hibernate-dev] [Search] Elasticsearch TermQuery translation

[Guillaume Smet]

Hi Gunnar,

In ToElasticsearch, you have translated the Lucene TermQuery to a match
query [1] in Elasticsearch.

>From what I see, it should be a term query [2] instead. Don't you agree?

[1]
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-match-query.html
[2]
https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-term-query.html

If you agree, I'll fix it in my tree.

FYI, I'm working on getting the DSLTest working.

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

Re: [hibernate-dev] [Search] Elasticsearch TermQuery translation

[Guillaume Smet]

On Thu, Feb 25, 2016 at 4:03 PM, Gunnar Morling 
wrote:

> @Guillaume, do you think you could provide the fix for such release?
> It's ok if still some tests of DSLTest fail, any progress is
> beneficial.
>

Mmmh, I can push the fixes I made but we can't run the DSLTest yet as it's
depending on spatial (and we can't initialize spatial fields yet).

Or maybe, we should move the spatial stuff to another test? It makes sense
to me.

I'll see what I have tomorrow. Keep me posted of the release time.

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

[hibernate-dev] [Search] Elasticsearch - Thoughts about analyzers and fieldbridges

[Guillaume Smet]

Hi,

Running the DSLTest is quite interesting as it runs a lot of different
queries with different configurations.

Here are some thoughts while working on it.

1/ Analyzers
=

Gunnar, I was wondering what you had in mind for analyzers: a) deal with
them in Hibernate Search or b) let Elasticsearch do the analyze thingy.

I'm not sure we can get a/ to work correctly (see below) and for b) we're
going to need a way to disable the analyzers in Search for the entities
managed by Elasticsearch.

Take a phrase query "colder and whitening" extracted from DSLTest. As "and"
is considered a stopword, the resulting PhraseQuery only contains colder &
whitening so it's not possible to rebuild the phrase before sending it to
Elasticsearch. We could try to use span queries but I'm not sure we'll be
able to get it right with synonyms and so on.

2/ FieldBridges
===

Currently, the conversion from Date to JSON string is managed by a
fieldbridge specific to the Elasticsearch backend (and it's not that easy
to plug it in as we have seen it in a ticket).

I'm wondering if it's a good fit and if we should not invent an entirely
new thing to deal with the transformation between a given Java type and
what a backend is waiting for.

What made me think of it is that a test from DSLTest is using
ignoreFieldBridge() on a date field and it disables the Date -> JSON string
conversion entirely.

Comments, thoughts?

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

[hibernate-dev] [Search] Elasticsearch - Translating exceptions?

[Guillaume Smet]

Hi,

I have a question regarding the Elasticsearch backend: should we try to
translate the Elasticsearch exceptions to Hibernate Search exceptions (the
ones from the loggers) when possible?

Good examples of it are in
SpatialIndexingTest#testNonGeoDistanceSortOnNonSpatialField and
#testNonGeoDistanceSortOnMissingField.

I think it might make sense for these particular examples but I wonder if
it won't be a maintenance burden in the long term.

Thoughts?

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

[hibernate-dev] README.adoc of hibernate.org

[Guillaume Smet]

Hi,

While setting up my environment for hibernate.org and in.relation.to, I
noticed that there are broken links in the README... when we read it on
GitHub (the .adoc extension is missing). It works OK when we read it from
the website using http://hibernate.org/README/.

I expect most people to use GitHub to read this document and the other ones
related (docker/README.adoc, survival-guide.adoc).

I was thinking about adding these files to .awestruct_ignore so that we
don't generate website pages for them and fix them for GitHub browsing.

Anyone against it?

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

Re: [hibernate-dev] To require or not to require a JIRA for a small-typo kind of commit

[Guillaume Smet]

OK for me too. That's what I was told when I asked the question a while ago
:).

On Mon, Apr 18, 2016 at 2:15 PM, Sanne Grinovero 
wrote:

> This question came up again on github; seems Gunnar, Davide and myself
> would agree on preferring a little more flexibility on the no-orm
> projects than ORM's guidelines:
>
>  -
> https://github.com/hibernate/hibernate-search/pull/1064#issuecomment-211320931
>
>
> This flexibility would be a perk for regular contributors only so I
> don't feel a need to move our conclusions to a formal document, yet
> I'm bringing it up here so you can all see it, and voice concerns /
> approval now :)
>
> 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] HipChat integrations

[Guillaume Smet]

Hi Davide,

On Wed, Apr 20, 2016 at 7:21 PM, Davide D'Alto  wrote:

> Standup:
> https://hibernate.hipchat.com/addons/hc-standup?room=-1


+1


> Google hangout:
>
> https://hibernate.hipchat.com/addons/com.atlassian.hipchat.hangouts?room=2237794


+1 , would be very useful


> Guest history:
> https://hibernate.hipchat.com/addons/hipchat-guest-history?room=-1


+1


> Pingmonit (might be useful to monitor hibernate.org, in relation.to, and
> ci.hibernate.org):
>
> https://hibernate.hipchat.com/addons/com.pingmonit.addons.hipchat?room=2237794


+1 if it doesn't generate too much false positives.

> Hipchat to issue:
>
https://marketplace.atlassian.com/plugins/com.keplerrominfo.plugins.hipchat.hipchatissue/cloud/overview

Hmmm, not sure it's a good idea. It might integrate some noise in the
issues if people are discussing different subjects.

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

Re: [hibernate-dev] GSoC 2016: Congratulations, your proposal with JBoss Community has been accepted!

[Guillaume Smet]

Welcome aboard, Mincong!

On Sat, Apr 23, 2016 at 5:44 PM, Steve Ebersole  wrote:

> Congrats and thanks to you Mincing :)
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] NoORM IRC meeting transcripts

[Guillaume Smet]

Hi everyone,

Here are the transcripts of this week's NoORM IRC meeting.

15:47 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-04-26-13.01.html
15:47 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-04-26-13.01.txt
15:47 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-04-26-13.01.log.html

First meeting as chair so there are a couple of adjustments to make.

See you next time!

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

[hibernate-dev] NoORM IRC meeting transcripts

[Guillaume Smet]

Hi everyone,

Here are the transcripts of this week's NoORM IRC meeting.

15:26 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.html
15:26 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.txt
15:26 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-05-10-12.34.log.html

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

Re: [hibernate-dev] Search: renaming whole package (!)

[Guillaume Smet]

Hi Sanne,

Nothing here, thanks for asking.

AFAICS the only remaining PR is
https://github.com/hibernate/hibernate-search/pull/1104 . I'm not that good
in concurrency issues so I prefer to let someone else check it.

-- 
Guillaume

On Thu, May 19, 2016 at 7:24 PM, Sanne Grinovero 
wrote:

> One of the last pending tasks for the Elasticsearch work is to
> mass-rename all packages from
>
> org.hibernate.search.backend.elasticsearch.*
>
> to
>
> org.hibernate.search.elasticsearch.*
>
> It's trivial to do, but before proceeding I'd like to make sure that
> all your important work was merged. All ready to proceed with this?
>
> I plan to do it tomorrow at noon. If someone could merge the smaller
> pending PRs in the meantime that would be nice.
>
> 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] [ORM] EhCache 3 and JCache

[Guillaume Smet]

Hi,

On Fri, May 20, 2016 at 9:54 AM, Emmanuel Bernard 
wrote:

> 3. change the Ehcache module and move it from v2 to v3
>

Please don't do that.

I'm pretty sure users will need to test Ehcache 3 before going live and it
shouldn't be tied to an Hibernate upgrade. Cache is a very sensible subject
and I'm pretty sure moving to Ehcache 3 will come with its challenges. We
should at least have 1 or 2 versions allowing both Ehcache 2 and 3.

Moreover, last time I checked, there was no Jgroups replication yet in
Ehcache 3 (or it's not documented).

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

[hibernate-dev] NoORM IRC meeting transcripts

[Guillaume Smet]

Hi everyone!

Here are the transcripts of this week's NoORM IRC meeting:
15:54 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-07-13.04.html
15:54 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-07-13.04.txt
15:54 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-07-13.04.log.html

See you next time!

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

[hibernate-dev] NoORM IRC meeting transcripts

[Guillaume Smet]

Hi everyone,

Here are the transcripts of this week's NoORM IRC meeting.

16:32 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-21-13.05.html
16:32 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-21-13.05.txt
16:32 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-06-21-13.05.log.html

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

[hibernate-dev] Redis and TTL

[Guillaume Smet]

Hi,

So, I'm currently working on reducing the number of calls issued to Redis
in OGM as part of OGM-1064.

At the moment, we execute a call to Redis to get the TTL already configured
on an object before saving it. If the TTL is not explicitly configured with
@TTL, we set this TTL again after having stored this entity (see
RedisJsonDialect#storeEntity). Same for associations stored in a different
document.

In fact, this call returns the time remaining before expiration, not the
TTL previously configured,  so I find this behavior quite weird. Basically,
we store information which will expire sooner than expected. I can't really
get a use case for this and I don't think we should have an additional call
every time we store an object for a so obscure thing. Do we really expect
people to mess with TTLs of objects stored by OGM without relying on OGM
@TTL management?

IMHO, we should get rid of this call and only deal with TTL when it's
configured via the @TTL annotation.

Thoughts?

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

Re: [hibernate-dev] Redis and TTL

[Guillaume Smet]

Hi Mark!

Thanks for commenting on this, I was hoping for it.

While I can see the use case for sharing Redis data between 2 tools, I must
admit that I find it a bit weird to set the TTL on one tool and store the
entity on another one. It looks to me that if OGM stores the data, it has
to manage also the expiration.

Otherwise you store data from OGM which might expire in a few seconds if
you're not lucky!

Don't you agree?

-- 
Guillaume

On Mon, Jun 27, 2016 at 3:47 PM, Mark Paluch  wrote:

>
> Hi Guillaume,
>
> TTL preservation behavior originates from Redis’ behavior and is to
> preserve interoperability:
>
> http://redis.io/commands/set
>
> Set key to hold the string value. [...] Any previous time to live
> associated with the key is discarded on successful SET operation.
>
>
> Keys written with SET loose their TTL value and the entry is persisted
> without any further TTL. Reading and re-applying TTL is to preserve the
> expiry.
> The general idea behind is to either apply the remaining TTL from the key,
> because TTL is not configured in the entity model or to set the configured
> TTL from the entity model.
> I see it from an integration-perspective in which Hibernate OGM and other
> tools share Redis data and so you’re opting-in for features but things are
> not broken.
>
> Best regards, Mark
>
>
> Am 27.06.2016 um 14:43 schrieb Guillaume Smet :
>
> Hi,
>
> So, I'm currently working on reducing the number of calls issued to Redis
> in OGM as part of OGM-1064.
>
> At the moment, we execute a call to Redis to get the TTL already configured
> on an object before saving it. If the TTL is not explicitly configured with
> @TTL, we set this TTL again after having stored this entity (see
> RedisJsonDialect#storeEntity). Same for associations stored in a different
> document.
>
> In fact, this call returns the time remaining before expiration, not the
> TTL previously configured,  so I find this behavior quite weird. Basically,
> we store information which will expire sooner than expected. I can't really
> get a use case for this and I don't think we should have an additional call
> every time we store an object for a so obscure thing. Do we really expect
> people to mess with TTLs of objects stored by OGM without relying on OGM
> @TTL management?
>
> IMHO, we should get rid of this call and only deal with TTL when it's
> configured via the @TTL annotation.
>
> 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] Redis and TTL

[Guillaume Smet]

I might be dumb but I can't figure out a use case where you would want an
external app to set a TTL and OGM to manipulate the same objects while
keeping the TTL originally set. It really looks weird to me.

Anyway, if it's really a use case, I think Gunnar's proposal does fit and
will allow to remove these useless pttl calls.

As for the dynamic TTL based on a property/method, let's keep it for
another day.

Mark, do you wish to make a proposal on the REFRESH/KEEP thing or should I
take it from there?

Btw, as far as I'm concerned, I would use @TTL because even if you want to
use the KEEP option, you probably would want to set a TTL if the entity
doesn't exist yet? What I would do is: if there is already a TTL for this
object, keep it, if not use the TTL defined in @TTL. But as I didn't
understand the original use case, I wouldn't bet on it :).

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

[hibernate-dev] Released: Hibernate Search 5.5.4.Final

[Guillaume Smet]

Hello everyone,

A maintenance release of our latest stable branch, version 5.5.4.Final
of Hibernate Search is now available, and is the suggested stable
version for everyone to use.

More details about the improvements can be found on our blog:
 - 
http://in.relation.to/2016/06/29/Polishing-Polishing-And-More-Polishing-Hibernate-Search-5-5-4-Final/

Have a nice day!

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

Re: [hibernate-dev] [OGM] Mapping of component types in document stores

[Guillaume Smet]

Hi,

For the sake of completeness, here is the mapping obtained with Morphia:
{ "_id" : ObjectId("5784ca2612d0226cb309666d"), "className" :
"TestEntity", "embeddeds" : [ { "singleProperty" : "value1" }, {
"singleProperty" : "value2" } ], "embedded" : { "singleProperty" :
"value" }, "collectionOfStrings" : [ "string1", "string2" ] }
They are basically following the POLA and follow the Java mapping for
the MongoDB one.

Btw, to be complete, here are the reasons why I would like to change
it (I agree we have to maintain compatibility with older databases
but, as Sanne, I think it should be the new default):
1/ POLA: I would expect my datastore mapping to follow my Java mapping
2/ related to 1/: I wouldn't expect to have to migrate my data when I
simply add a property to an existing embeddable
3/ remove special cases in our code, especially special cases present
in the dialects
4/ I don't think we are completely consistent with this behavior.
Typically, if I take StoryGame from our tests and remove all the
properties but one from OptionalStoryBranch, I end up with the
following:
- in the datastore: "chaoticBranches" : [ "[VENDETTA] assassinate the
leader of the party", "[ARTIFACT] Search for the evil artifact" ] -
this is what we expect, only one property, we remove the property
level
- in the native query generated by our JPA query "FROM StoryGame story
JOIN story.chaoticBranches c WHERE c.evilText = '[ARTIFACT] Search for
the evil artifact'": where={ "chaoticBranches.evilText" : "[ARTIFACT]
Search for the evil artifact"}
-> so our JPQL queries don't work if we only have one property in the
embedded. We might also want to special case this but I really don't
think it's a good idea.

While this discussion might seem to come out of the blue, it's in fact
related to OGM-893 and another special casing we do. See my comment
here: 
https://hibernate.atlassian.net/browse/OGM-893?focusedCommentId=79245&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-79245
. The mapping is changing when we add a @Column with a name for a
property of an embedded in a collection element.

-- 
Guillaume

On Tue, Jul 12, 2016 at 12:18 PM, Sanne Grinovero  wrote:
> On 12 July 2016 at 11:13, Gunnar Morling  wrote:
>>> I'd be concerned about schema evolution:
>>
>> Yes, that's the main argument; as said, I can see that.
>>
>>> I'd see more value in making this the default, and have an "higher
>>> level" configuration property which is like "read like OGM 5.0 used to
>>> store it".
>>
>> I wouldn't like changing such default in a 5.x release. For 6, ok, why not,
>> if you all think that's better.
>
> ok
>
>>
>>> Even better, we'd provide tooling which migrates an existing database.
>>
>> Sure, migration support is on the roadmap ;)
>>
>>
>>
>>
>>
>> 2016-07-12 11:06 GMT+01:00 Sanne Grinovero :
>>>
>>> On 12 July 2016 at 10:55, Gunnar Morling  wrote:
>>> > Hi,
>>> >
>>> > We had an interesting discussion on how to map element collections of
>>> > component types with a single column to document stores such as MongoDB.
>>> >
>>> > E.g. assume we have
>>> >
>>> > @Entity
>>> > public class Person {
>>> >
>>> > public String name;
>>> >
>>> > @ElementCollection
>>> > public List statusHistory;
>>> > }
>>> >
>>> > @Embeddable
>>> > public class Status {
>>> > public String name;
>>> > }
>>> >
>>> >
>>> > Currently, that's mapped to documents like this:
>>> >
>>> > {
>>> > "name"  : "Bob";
>>> > "statusHistory" : [
>>> > "great",
>>> > "mediocre",
>>> > "splendid"
>>> > ]
>>> > }
>>>
>>> "great", "mediocre", etc.. are values of the `name` property?
>>>
>>> >
>>> > I.e. if the component type has a single column, we omit the field name
>>> > in
>>> > the persistent structure. Whereas if there are multiple columns, it's
>>> > added
>>> > so we can properly read back such documents:
>>> >
>>> >
>>> > {
>>> > "name"  : "Bob";
>>> > "statusHistory" : [
>>> > { "name" : "great", "date" : "22.06.2016" },
>>> > { "name" : "mediocre", "date" : "15.05.2016" },
>>> > { "name" : "splendid", "date" : "12.04.2016" }
>>> > ]
>>> > }
>>> >
>>> > The question now is, should we also create such array of sub-documents,
>>> > each containing the field name, in the case where there only is a single
>>> > column. As far as I remember, the current structure has been chosen for
>>> > the
>>> > sake of efficiency but also simplicity (why deal with sub-documents if
>>> > there only is a single field?).
>>> >
>>> > Guillaume is questioning the sanity of that, arguing that mapping this
>>> > as
>>> > an element collection of a component type rather than string should
>>> > mandate
>>> > the persistent structure to always contain the field name.
>>>
>>> I agree, but maybe for other reasons.
>>> I'd be concerned about schema evolution: if I add a new attribut

[hibernate-dev] [OGM] Mapping of embedded

[Guillaume Smet]

Hi,

This is a followup of:
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Mapping of embedded

[Guillaume Smet]

So this is a followup of my previous email (looks like I found out the
Send shortcut on GMail...)... which was supposed to be a followup of:
 * https://hibernate.atlassian.net/browse/OGM-893
 * https://github.com/hibernate/hibernate-ogm/pull/728
 * and a discussion we had yesterday with Davide.

Taking MongoDB as the reference implementation here.

Current situation
=

1/ for a simple embedded Address (property: homeAddress) with one of
the property having a @Column(name = "postal_code"), we end up with
the following mapping:
{
[...],
'homeAddress' : {
'city' : 'Paris',
'country' : 'France',
'street1' : '1 avenue des Champs Elysees',
'type' : {
'name' : 'main'
}
},
'postal_code' : '75007',
[...]
}
As you can see, postal_code is stored outside of the nested structure.
This is in line with the ORM behavior where you end up having the
columns homeAddress_city and postal_code.

Of course, this is a bit weird when we are considering nested documents.

See EmbeddableMappingTest for reference.

2/ now suppose that we have a List, the current mapping is
the following:
{
[...],
"addresses": [
   {
   "addresses": {
   "country": "Germany",
   "city": "Paris",
   "street1": "1 avenue des Champs Elysees"
   },
"postal_code": "75007"
   },
   {
   "addresses": {
   "city": "Rome",
   "street1": "Piazza del Colosseo, 1",
   "type": {
   "name": "primary"
   }
   },
"postal_code": "00184"
   }
],
[...]
}

Note the fact that addresses is nested twice.

This is discussed at length in https://hibernate.atlassian.net/browse/OGM-893.

What does PR 728 change?


After the work we did with Steve on ORM and the followup of Davide on
OGM, we end up with the following situation:

1/ Same as before. postal_code is outside of the nested document.

2/ This is where the behavior has changed, we now have the following mapping:
{
"addresses": [
   {
   "country": "Germany",
   "city": "Paris",
   "street1": "1 avenue des Champs Elysees",
   "postal_code": "75007"
   },
   {
   "city": "Rome",
   "street1": "Piazza del Colosseo, 1",
   "type": {
   "name": "primary"
   },
   "postal_code": "00184"
   }
],
}

Note that postal_code and city are now at the same level.

See this future test executed on top of pr/728:
https://gist.github.com/gsmet/0652294523b2c48efe72668ccc0a6e1c

Conclusion
==

So as you can see, the mapping is quite different between a simple
embedded and a list of embedded. I was not very happy with the
behavior of 2/ before, especially because if you remove the @Column,
you lose the data stored. Same if you didn't have one before and you
add one to your embeddable.

But I'm also not convinced having a different behavior between 1/ and
2/ is the way to go. Note that, from what I've seen, I don't think
changing 1/ to move postal_code in the nested document will be easy
(or even feasible).

Opinions? Thoughts?

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

[hibernate-dev] People can't find our docs

[Guillaume Smet]

Hi,

When we search for Hibernate/Hibernate Search issues, Google send
people to *very* outdated docs.

For instance, searching for %1$s gets me to %2$s:
- hibernate collection element ->
https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/collections.html
(yes, *3.3*)
- hibernate search facet ->
https://docs.jboss.org/hibernate/search/4.5/reference/en-US/html/search-query.html

These versions of our docs are very well indexed by Google as they
come up before stack overflow but it's really a bad thing to get
people directed to very old versions of our documentation.

Do we have people at RH working on this sort of things who could help
us defining a good strategy to improve that? Did anyone already take a
look at this?

When I was contributing to PostgreSQL, the subject was discussed at
length and they didn't find a good solution at the time to get Google
to preferably link to the last version. Using canonical urls for
instance requires you to regenerate all the old docs when you have to
point to another URL.

They finally decided to integrate links to all versions at the top of
each doc page: https://www.postgresql.org/docs/9.5/static/sql-syntax.html
.


>From my point of view, here are a few things that might help mitigate the 
>issue:
- have a version of the doc labelled as /current/ (or /stable/) on
hibernate.org. From what I've seen, ORM has a /current/ symlink but
it's currently pointing to the 5.1 documentation and is not used on
the website. We should use this link every time we link to the
documentation (especially on SO).

- Maybe we could try to map the old URLs to the new ones by doing
something similar to what PostgreSQL does but dynamically with jQuery.
We could inject it in the old documentation with something like
http://httpd.apache.org/docs/2.2/mod/mod_substitute.html if we can get
this enabled on docs.jboss.org.

- our doc URLs are now named chNN.html which is not very future proof.
Did we have issues keeping the semantic ones? I suppose it's related
to the asciidoc migration? It would be a good way to keep more stable
URL.

- btw, is there a reason why we only generate the html_single output
for Hibernate ORM?

Thoughts, opinions, ideas?

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

Re: [hibernate-dev] People can't find our docs

[Guillaume Smet]

Hi Sanne,

Thanks for your feedback. I was pretty sure I hadn't all the history!

Getting Google to prioritize our latest doc is probably a long time goal.

I played a bit with jQuery to suggest to the user to go to the latest
stable. Note that I only took into consideration the page for the time
being and didn't consider the anchor but it should be easy to add it
if we think it's worth it (it's a lot more work on the json descriptor
though).

The following command for each version is all that is needed:
sed -i 's@@http://code.jquery.com/jquery-3.1.0.min.js";
integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
crossorigin="anonymous">@' *.html
(or a find -exec to do it on all the versions at once)

I attached the global json descriptor and the js file. Both should be
added to /hibernate/search/. Note that I only did the work for version
4.5 in the json descriptor. The work for other versions would mostly
be a copy/paste.

I also attached a screenshot of how it looks like. Nothing fancy but
we can do whatever we want.

Note that I only targeted the multi page HTML output as it was the
most interesting to prototype.

When we release a new version, we would have to update the descriptor file.

Comments?

-- 
Guillaume

On Tue, Jul 19, 2016 at 2:39 PM, Sanne Grinovero  wrote:
> Hi Guillaume,
>
> yes I'm aware of the issue; we discussed it before, I think on this
> same mailing list but maybe it was during our last meeting.
>
> We really need to fix that metadata; Stefania (my partner) is an SEO
> consultant and is shocked at how bad we do with this; apparently we
> are a funny example in her office but at least we're not the worst :)
>
> The problem is we can't change the headers as we don't control the
> Apache httpd configuraion on the documentation server, so the
> alternative is we'd need to rsync those docs locally, insert the right
> changes in the static files of the docs, and push them back.
>
> Needs a volunteer to find some time for this.
>
> Also related to SEO I recently opened some issues on our WEBSITE
> project, these should be easier to fix as it's directly under our
> control:
>  - https://hibernate.atlassian.net/browse/WEBSITE-461
>  - https://hibernate.atlassian.net/browse/WEBSITE-460
>  - https://hibernate.atlassian.net/browse/WEBSITE-459
>
> I've assigned them to Davide as he's usually quick with such things
> but anyone is welcome to take some.
>
> The metadata issue on the docs server is probably the most urgent /
> valuable though.
>
> Thanks,
> Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] People can't find our docs

[Guillaume Smet]

Hi Sanne,

Thanks for your feedback. I was pretty sure I hadn't all the history!

Getting Google to prioritize our latest doc is probably a long time goal.

I played a bit with jQuery to suggest to the user to go to the latest
stable. Note that I only took into consideration the page for the time
being and didn't consider the anchor but it should be easy to add it
if we think it's worth it (it's a lot more work on the json descriptor
though).

The following command for each version is all that is needed:
sed -i 's@@http://code.jquery.com/jquery-3.1.0.min.js";
integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
crossorigin="anonymous">@' *.html
(or a find -exec to do it on all the versions at once)

I attached the global json descriptor and the js file (with a .txt
extension as it didn't pass the mail filter). Both should be added to
/hibernate/search/. Note that I only did the work for version 4.5 in
the json descriptor. The work for other versions would mostly be a
copy/paste.

I also attached a screenshot of how it looks like. Nothing fancy but
we can do whatever we want.

Note that I only targeted the multi page HTML output as it was the
most interesting to prototype.

When we release a new version, we would have to update the descriptor file.

Comments?

--
Guillaume

On Tue, Jul 19, 2016 at 2:39 PM, Sanne Grinovero  wrote:
> Hi Guillaume,
>
> yes I'm aware of the issue; we discussed it before, I think on this
> same mailing list but maybe it was during our last meeting.
>
> We really need to fix that metadata; Stefania (my partner) is an SEO
> consultant and is shocked at how bad we do with this; apparently we
> are a funny example in her office but at least we're not the worst :)
>
> The problem is we can't change the headers as we don't control the
> Apache httpd configuraion on the documentation server, so the
> alternative is we'd need to rsync those docs locally, insert the right
> changes in the static files of the docs, and push them back.
>
> Needs a volunteer to find some time for this.
>
> Also related to SEO I recently opened some issues on our WEBSITE
> project, these should be easier to fix as it's directly under our
> control:
>  - https://hibernate.atlassian.net/browse/WEBSITE-461
>  - https://hibernate.atlassian.net/browse/WEBSITE-460
>  - https://hibernate.atlassian.net/browse/WEBSITE-459
>
> I've assigned them to Davide as he's usually quick with such things
> but anyone is welcome to take some.
>
> The metadata issue on the docs server is probably the most urgent /
> valuable though.
>
> Thanks,
> Sanne
$(document).ready(function() {
$.getJSON('/hibernate/search/documentation.json', function (json) {
var currentUrl = window.location.pathname;
var match = new RegExp('^' + json.pattern.replace('${version}', 
'([^/]+)').replace('${page}', '(.+\\.html)') + '$').exec(currentUrl);
if (match.length != 3) {
return;
}
var currentVersion = match[1];
var currentPage = match[2];
var currentHash = window.location.hash;

if (currentVersion == json.stable || currentVersion == 
json.development || currentVersion == 'stable') {
return;
}

var redirectPage;
if (currentVersion in json.versions && currentPage in 
json.versions[currentVersion].redirects) {
redirectPage = 
json.versions[currentVersion].redirects[currentPage];
} else {
redirectPage = '';
}
stableUrl = json.pattern.replace('${version}', 
json.stable).replace('${page}', redirectPage + currentHash);
$('head').append('' +
'.outdated-content {' +
'   position: fixed;' +
'   bottom: 0;' +
'   left: 0;' +
'   text-align:center;' +
'   width:100%;' +
'   padding: 20px;' +
'   background-color: orange;' +
'   background-color: #ffbc3b;' +
'   border-top: 1px solid orange;' +
'   font-weight: bold;' +
'   font-size: 20px;' +
'   color: white;' +
'   text-shadow: 0 1px 1px rgba(85, 85, 85, 0.55)' +
'}' +
'a.version {' +
'   border: 1px solid #AAA;' +
'   border-radius: 4px;' +
'   background-color: #BBB;' +
'   padding: 3px 8px;' +
'   color: white;' +
'   text-shadow: 0 1

Re: [hibernate-dev] People can't find our docs

[Guillaume Smet]

Hi all!

So here is a status of what I did:
- I updated the /stable/ link of ogm from 3.0 (cough, cough) to 5.0:
http://docs.jboss.org/hibernate/stable/ogm/reference/en-US/html/: we
need to include this in our release process.
- I updated the /current/ symlink of ORM to point to 5.2 instead of
5.1: it needs to be integrated in the release process; (the /stable/
link uses the /current/ symlink so it's also fixed)
- I removed the docs for OGM 3.0 as they were a copy of the doc of OGM 4.2

Next, I applied some magic to 2 old versions of OGM and Search so that
you can check everything is OK for you before I generalize it:
- Add meta description and keywords
- Add a canonical link to the /stable/ single html version
- Add a piece of Javascript to warn the user and propose to redirect
him to the best possible place of our last stable release
documentation

See the 2 examples here:
http://docs.jboss.org.local/hibernate/ogm/4.1/reference/en-US/html/ogm-architecture.html
(scroll to see the hash tracker in action)
http://docs.jboss.org/hibernate/search/4.2/reference/en-US/html/search-architecture.html

See the current code and descriptors here:
https://docs.jboss.org/hibernate/_outdated-content/

The script and the descriptors work for all existing versions of the
OGM and Search doc.

The marker to include in the docs looks like that:


$(document).ready(function() {
HibernateDoc.OutdatedContent.install("search"); });

(I'm using a CDN but maybe we should host jQuery on docs.jboss.org?)

The script is capable to redirect either to the multi page version
(using the redirects declared in the JSON file: it automatically
cumulates the redirects from version X to version Y so we don't need
that much metadata) or to the single page version by leveraging the
anchors and hashes. For now, I decided to push the user to the single
page version as it's the one we use for the canonical link but we can
of course discuss it. Note that I add a ?v=X.X parameter to be sure
the user is redirected to a fresh version of the corresponding
/stable/ page and not a cache. I had the issue a couple of times.

Next if you like it:
- generalize it to all the existing versions of the docs, sed FTW
- modify the Hibernate XSL stylesheets to include it in the newly generated ones
- probably modify our website so that the stable release points to the
/stable/ link to the docs
- do the same for Validator

@ORM: interested in me pursuing this for ORM too? It will probably be
a lot more work as the structure of the docs got changed a lot.

Comments, opinions, thoughts welcome.

-- 
Guillaume

On Wed, Jul 20, 2016 at 12:06 PM, Davide D'Alto  wrote:
> I'll try to apply these changes on Friday.
>
> Davide
>
> On Tue, Jul 19, 2016 at 11:53 PM, Guillaume Smet
>  wrote:
>> Hi Sanne,
>>
>> Thanks for your feedback. I was pretty sure I hadn't all the history!
>>
>> Getting Google to prioritize our latest doc is probably a long time goal.
>>
>> I played a bit with jQuery to suggest to the user to go to the latest
>> stable. Note that I only took into consideration the page for the time
>> being and didn't consider the anchor but it should be easy to add it
>> if we think it's worth it (it's a lot more work on the json descriptor
>> though).
>>
>> The following command for each version is all that is needed:
>> sed -i 's@@> src="<a  rel="nofollow" href="http://code.jquery.com/jquery-3.1.0.min.js"">http://code.jquery.com/jquery-3.1.0.min.js"</a>;
>> integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
>> crossorigin="anonymous">> src="/hibernate/search/outdated-version.js">@' *.html
>> (or a find -exec to do it on all the versions at once)
>>
>> I attached the global json descriptor and the js file (with a .txt
>> extension as it didn't pass the mail filter). Both should be added to
>> /hibernate/search/. Note that I only did the work for version 4.5 in
>> the json descriptor. The work for other versions would mostly be a
>> copy/paste.
>>
>> I also attached a screenshot of how it looks like. Nothing fancy but
>> we can do whatever we want.
>>
>> Note that I only targeted the multi page HTML output as it was the
>> most interesting to prototype.
>>
>> When we release a new version, we would have to update the descriptor file.
>>
>> Comments?
>>
>> --
>> Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] People can't find our docs

[Guillaume Smet]

Iiiik, remove the .local suffix in the domain for the first example!

On Thu, Jul 21, 2016 at 1:33 PM, Guillaume Smet
 wrote:
> Hi all!
>
> So here is a status of what I did:
> - I updated the /stable/ link of ogm from 3.0 (cough, cough) to 5.0:
> http://docs.jboss.org/hibernate/stable/ogm/reference/en-US/html/: we
> need to include this in our release process.
> - I updated the /current/ symlink of ORM to point to 5.2 instead of
> 5.1: it needs to be integrated in the release process; (the /stable/
> link uses the /current/ symlink so it's also fixed)
> - I removed the docs for OGM 3.0 as they were a copy of the doc of OGM 4.2
>
> Next, I applied some magic to 2 old versions of OGM and Search so that
> you can check everything is OK for you before I generalize it:
> - Add meta description and keywords
> - Add a canonical link to the /stable/ single html version
> - Add a piece of Javascript to warn the user and propose to redirect
> him to the best possible place of our last stable release
> documentation
>
> See the 2 examples here:
> http://docs.jboss.org.local/hibernate/ogm/4.1/reference/en-US/html/ogm-architecture.html
> (scroll to see the hash tracker in action)
> http://docs.jboss.org/hibernate/search/4.2/reference/en-US/html/search-architecture.html
>
> See the current code and descriptors here:
> https://docs.jboss.org/hibernate/_outdated-content/
>
> The script and the descriptors work for all existing versions of the
> OGM and Search doc.
>
> The marker to include in the docs looks like that:
>  integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
> crossorigin="anonymous">
>  type="text/javascript">
> $(document).ready(function() {
> HibernateDoc.OutdatedContent.install("search"); });
>
> (I'm using a CDN but maybe we should host jQuery on docs.jboss.org?)
>
> The script is capable to redirect either to the multi page version
> (using the redirects declared in the JSON file: it automatically
> cumulates the redirects from version X to version Y so we don't need
> that much metadata) or to the single page version by leveraging the
> anchors and hashes. For now, I decided to push the user to the single
> page version as it's the one we use for the canonical link but we can
> of course discuss it. Note that I add a ?v=X.X parameter to be sure
> the user is redirected to a fresh version of the corresponding
> /stable/ page and not a cache. I had the issue a couple of times.
>
> Next if you like it:
> - generalize it to all the existing versions of the docs, sed FTW
> - modify the Hibernate XSL stylesheets to include it in the newly generated 
> ones
> - probably modify our website so that the stable release points to the
> /stable/ link to the docs
> - do the same for Validator
>
> @ORM: interested in me pursuing this for ORM too? It will probably be
> a lot more work as the structure of the docs got changed a lot.
>
> Comments, opinions, thoughts welcome.
>
> --
> Guillaume
>
> On Wed, Jul 20, 2016 at 12:06 PM, Davide D'Alto  wrote:
>> I'll try to apply these changes on Friday.
>>
>> Davide
>>
>> On Tue, Jul 19, 2016 at 11:53 PM, Guillaume Smet
>>  wrote:
>>> Hi Sanne,
>>>
>>> Thanks for your feedback. I was pretty sure I hadn't all the history!
>>>
>>> Getting Google to prioritize our latest doc is probably a long time goal.
>>>
>>> I played a bit with jQuery to suggest to the user to go to the latest
>>> stable. Note that I only took into consideration the page for the time
>>> being and didn't consider the anchor but it should be easy to add it
>>> if we think it's worth it (it's a lot more work on the json descriptor
>>> though).
>>>
>>> The following command for each version is all that is needed:
>>> sed -i 's@@>> src="<a  rel="nofollow" href="http://code.jquery.com/jquery-3.1.0.min.js"">http://code.jquery.com/jquery-3.1.0.min.js"</a>;
>>> integrity="sha256-cCueBR6CsyA4/9szpPfrX3s49M9vUU5BgtiJj06wt/s="
>>> crossorigin="anonymous">>> src="/hibernate/search/outdated-version.js">@' *.html
>>> (or a find -exec to do it on all the versions at once)
>>>
>>> I attached the global json descriptor and the js file (with a .txt
>>> extension as it didn't pass the mail filter). Both should be added to
>>> /hibernate/search/. Note that I only did the work for version 4.5 in
>>> the json descriptor. The work for other versions would mostly be a
>>> copy/paste.
>>>
>>> I also attached a screenshot of how it looks like. Nothing fancy but
>>> we can do whatever we want.
>>>
>>> Note that I only targeted the multi page HTML output as it was the
>>> most interesting to prototype.
>>>
>>> When we release a new version, we would have to update the descriptor file.
>>>
>>> Comments?
>>>
>>> --
>>> Guillaume
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] People can't find our docs

[Guillaume Smet]

On Thu, Jul 21, 2016 at 2:07 PM, Emmanuel Bernard
 wrote:
> Should we add a X or I got it button to remove this nagging when I have
> to read and stay on the old doc?

I thought about it but I don't find it that invasive that we need to
add a close button. But I can do it if people think it's needed. I
suppose we would need a cookie to keep the information during the
navigation on the doc.

> If that piece of code is in the xsl, how will it work when the doc is in
> the distribution?

It won't work. It won't be able to load the Javascript files (the //
doesn't work with file:// protocol, and
/hibernate/_outdated-content/outdated-content.js will not be present).
I can make it work by using absolute URLs for everything but I thought
it was better to not have it in the distribution doc: if you have
downloaded a particular version of the doc, you probably want to read
this version.

> How screwed are you if we stop using these stylesheet and say embrace
> the Asciidoctor default style?

Well, either we can include top and bottom template anyway or we have
to run a sed on the files before uploading them to the doc server.

Maybe we should even do it this way and add the sed calls in our
release process. This way, it won't be in the distribution doc and we
won't have to alter the stylesheets.

Basically, we have to execute this in the reference directory (I
didn't do the work for the Javadoc, would it be useful?):
# Hibernate Search

find . -name \*.html -exec sed -i 's@@$(document).ready(function() {
HibernateDoc.OutdatedContent.install("search"); });@'
{} \;

find . -name \*.html -exec sed -i 's@https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/";
/>   markers to be able to update the
code easily in the future. Same for the meta.

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

Re: [hibernate-dev] People can't find our docs

[Guillaume Smet]

@Davide, @Sanne: would it be an issue to include the sed lines in our
release process to prepare the docs before uploading them to the doc
server?

If it's not, it's probably the best solution. I'll wait for your
confirmation before polishing them.

On Thu, Jul 21, 2016 at 2:38 PM, Emmanuel Bernard
 wrote:
> On Thu 2016-07-21 14:20, Guillaume Smet wrote:
>> On Thu, Jul 21, 2016 at 2:07 PM, Emmanuel Bernard
>>  wrote:
>> > Should we add a X or I got it button to remove this nagging when I have
>> > to read and stay on the old doc?
>>
>> I thought about it but I don't find it that invasive that we need to
>> add a close button. But I can do it if people think it's needed. I
>> suppose we would need a cookie to keep the information during the
>> navigation on the doc.
>>
>> > If that piece of code is in the xsl, how will it work when the doc is in
>> > the distribution?
>>
>> It won't work. It won't be able to load the Javascript files (the //
>> doesn't work with file:// protocol, and
>> /hibernate/_outdated-content/outdated-content.js will not be present).
>> I can make it work by using absolute URLs for everything but I thought
>> it was better to not have it in the distribution doc: if you have
>> downloaded a particular version of the doc, you probably want to read
>> this version.
>
> Right we should not have it.
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] People can't find our docs

[Guillaume Smet]

On Thu, Jul 21, 2016 at 3:06 PM, Sanne Grinovero  wrote:
> Maybe we could move that to the website, as similar metadata is
> already being deployed, e.g.
>  - 
> https://github.com/hibernate/hibernate.org/tree/staging/_data/projects/search/releases

We already need to update the /stable/ symlink on the doc server so we
might as well do it when we push the doc.

I got something like this:
https://gist.github.com/gsmet/8c8e29c46337f69bfbc9e84f108d951f . I'll
push a PR tomorrow.

I pushed the JS and the metadata to all known doc versions of Search and OGM.

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

Re: [hibernate-dev] [OGM] Mapping of embedded

[Guillaume Smet]

Hi all,

So after having discussed this issue with Emmanuel:

1/ is correct. It's the behavior we expect considering the ORM behavior. If we 
want the postal_code to be nested in homeAddress, we need to use @Column(name = 
"homeAddress.postal_code") or @AttributeOverride(name="zipCode", 
column=@Column(name="homeAddress.postal_code").

See the note here: 
http://docs.jboss.org/hibernate/ogm/5.0/reference/en-US/html_single/#d0e9677

[2/ current situation] was incorrect and needed to be fixed

[2/ after PR 728] is still incorrect

In this case, to have the postal_code nested in addresses, we would expect the 
user to use an @AttributeOverride to set the column name to 
addresses.postal_code.

So this is what we need to fix to be consistent:

List with Address>@Column("postal_code")
-> not supported

List with Address>@Column("addresses.postal_code") - probably not very 
useful in practice - or an @AttributeOverride(name="zipCode", 
column=@Column(name="addresses.postal_code") on the addresses property,
->
{
   "addresses": [
  {
  "country": "Germany",
  "city": "Paris",
  "street1": "1 avenue des Champs Elysees",
  "postal_code": "75007"
  },
  {
  "city": "Rome",
  "street1": "Piazza del Colosseo, 1",
  "type": {
  "name": "primary"
  },
  "postal_code": "00184"
  }
   ],
}

If we want to change that in the future (default to nested), we need to wait 
for OGM 6 and we will need ORM to keep the path information, which is not the 
case atm. So if we want to consider it, we probably need to ping Steve et al. 
about this.

We need to fix this before merging PR 728. Davide, do you take the lead on this 
or should I? I'm on vacation next week. 

We also need to add more tests for this behavior.

-- 
Guillaume

> On Wed, Jul 13, 2016 at 3:22 PM, Guillaume Smet  
> wrote:
> So this is a followup of my previous email (looks like I found out the
> Send shortcut on GMail...)... which was supposed to be a followup of:
> * https://hibernate.atlassian.net/browse/OGM-893
> * https://github.com/hibernate/hibernate-ogm/pull/728
> * and a discussion we had yesterday with Davide.
> 
> Taking MongoDB as the reference implementation here.
> 
> Current situation
> =
> 
> 1/ for a simple embedded Address (property: homeAddress) with one of
> the property having a @Column(name = "postal_code"), we end up with
> the following mapping:
> {
>[...],
>'homeAddress' : {
>'city' : 'Paris',
>'country' : 'France',
>'street1' : '1 avenue des Champs Elysees',
>'type' : {
>'name' : 'main'
>}
>},
>'postal_code' : '75007',
>[...]
> }
> As you can see, postal_code is stored outside of the nested structure.
> This is in line with the ORM behavior where you end up having the
> columns homeAddress_city and postal_code.
> 
> Of course, this is a bit weird when we are considering nested documents.
> 
> See EmbeddableMappingTest for reference.
> 
> 2/ now suppose that we have a List, the current mapping is
> the following:
> {
>[...],
>"addresses": [
>   {
>   "addresses": {
>   "country": "Germany",
>   "city": "Paris",
>   "street1": "1 avenue des Champs Elysees"
>   },
>"postal_code": "75007"
>   },
>   {
>   "addresses": {
>   "city": "Rome",
>   "street1": "Piazza del Colosseo, 1",
>   "type": {
>   "name": "primary"
>   }
>   },
>"postal_code": "00184"
>   }
>],
>[...]
> }
> 
> Note the fact that addresses is nested twice.
> 
> This is discussed at length in https://hibernate.atlassian.net/browse/OGM-893.
> 
> What does PR 728 change?
> 
> 
> After the work we did with Steve on ORM and the followup of Davide on
> OGM, we end up with the following situation:
> 
> 1/ Same as before. postal_code is outside of the nested document.
> 
> 2/ This is where the behavior has changed, we now have the following mapping:
> {
>"ad

Re: [hibernate-dev] [OGM] Mapping of embedded

[Guillaume Smet]

On Mon, Jul 25, 2016 at 2:10 PM, Emmanuel Bernard
 wrote:
> I am having second thoughts on the collection case. When I look at ORM's
> test suite and AttributeOverrideTest + PropertyRecord, the property name
> is not including the owning property (addresses in this case).
>
> @AttributeOverrides({
> @AttributeOverride(name = "size", column = 
> @Column(name = "SQUARE_FEET")),
> @AttributeOverride(name = "tax", column = 
> @Column(name = "ASSESSMENT"))
> })
> @ElementCollection
> public Set unsortedParcels;
>
> So we probably should not need to put "addresses" in the @Column for the 
> collection cases. It makes sense from an ORM PoV since we are talking about 
> different tables.

OK, so this means our current implementation is correct and we just
need to wait for 5.1.1 before merging pr/728.

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

[hibernate-dev] NoORM team meeting minutes

[Guillaume Smet]

Hi all,

Here are the transcripts of the NoORM team meeting:
16:12 < jbott> Meeting ended Tue Aug  2 14:12:04 2016 UTC.
Information about MeetBot at http://wiki.debian.org/MeetBot . (v
0.1.4)
16:12 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-02-13.02.html
16:12 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-02-13.02.txt
16:12 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-02-13.02.log.html

As for the next 2 months sprint, here is the current plan:
- Sanne: 1 month OGM to finish Hot Rod integration, Search on the side
and 1 month Search after that
- Davide: OGM to make progress on 5.1
- Guillaume: finish OGM-1064 + review, then either BV or Search + OGM PR buddy
- Gunnar: BV, probably some OGM review on the side
- Yoann: either Search or BV depending on Gunnar's feedback - we
thought it might be a good idea to make him start on the new Sort API
Emmanuel drafted for Search

We will discuss with Gunnar on Monday to decide what's the plan for
Yoann or me regarding BV/Validator.

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

Re: [hibernate-dev] Importing OGM in Eclipse: workaround needed [AKA: the domino effect of fixing your own tools..]

[Guillaume Smet]

Hi Sanne,

First, sorry for not mentioning it as I run into this problem a few
weeks ago. I must admit that, as noone complained about it, I thought
I was the only one with the problem and it was already fixed in recent
Neon releases.

The fact is that using maven-jar-plugin 3.0.0 is not an option as it
has memory issues. Yoann got them at OW and we had a few Travis build
failures on OGM because of that when I first upgraded to 3.0.0.

If we want to patch OGM, we have to go back to maven-jar-plugin 2.6
instead of 3.

Maybe we could ask Fred if an update is planned soon and decide with
that in mind?

-- 
Guillaume

On Tue, Aug 9, 2016 at 11:51 PM, Sanne Grinovero  wrote:
> Hi all,
> I was having critical issues with Eclipse / OGM after a recent rebase,
> which seemed was caused by:
>  - https://hibernate.atlassian.net/browse/OGM-1102
>
> The new maven-jar-plugin is no longer compatible with latest m2e
> integration, Fred Bricon already published an m2e preview with a fix;
> if you have this problem use this updated site to update m2e:
>  - 
> https://otto.takari.io/content/sites/m2e.extras/m2eclipse-mavenarchiver/0.17.2/N/LATEST/
>
> But there's a punch line.. the compatibility was broken because
> plex-tools, a dependency of maven-jar-plugin, was upgraded .. who
> would ever do such a thing!!! what an idiot :D :
>  - https://issues.apache.org/jira/browse/MJAR-205
>
> As an alternative to update m2e could apply this patch:
>  - 
> https://github.com/hibernate/hibernate-ogm/commit/36b37f76215e52b235ed362e6be0f7d40a4a12e9
>
> I'm tempted to throw my patch away and stick to the m2e preview.. let
> me know if you all prefer me to apply the workaround on OGM.. the
> benefit would be that Eclipse Neon would be able to import OGM out of
> the box, however I expect m2e will automatically update soon enough.
>
> At least I had an honest LOL..
>
> Cheers,
> 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] Importing OGM in Eclipse: workaround needed [AKA: the domino effect of fixing your own tools..]

[Guillaume Smet]

On Wed, Aug 10, 2016 at 12:18 PM, Gunnar Morling  wrote:
> Yes, any solution not requiring manual interfering would be preferred, but I
> understood Guillaume that the workaround is not really viable:
>
>> The fact is that using maven-jar-plugin 3.0.0 is not an option as it
> has memory issues
>
> Or did I miss something?

Yup, you missed this from Sanne:
> That's why my workaround overrides the version of maven-archiver :
> essentially it cherry picks the memory bugfix w/o the other changes.

+1 to apply the workaround.

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

Re: [hibernate-dev] People need an Hibernate Search release to match ORM 5.2

[Guillaume Smet]

Hi Sanne,

I had the same thought a few days ago. At Open Wide, we used to follow
the ORM versions very closely and we usually had a corresponding
Search version very soon.

I agree we need to release something compatible with ORM 5.2 sooner
rather than later.

I understand your concern about bringing Elasticsearch to WildFly
users but it feels quite weird for a "product" version to be the
reference for our community work.

IMHO, it would make more sense to have our main development efforts on
a community release backed by 5.2 and eventually backport the
Elasticsearch work to 5.6 and make a 5.6 release if it ends up to be
useful for product.

-- 
Guillaume

On Thu, Aug 11, 2016 at 3:11 PM, Sanne Grinovero  wrote:
> Hi all,
> as you might be aware, ORM 5.2 made some rather radical internal work,
> and the latest Hibernate Search releases aren't compatible.
>
> So far, business as usual: we typically simply catch up on the next minor.
>
> The problem is that normally Hibernate Search releases are time-boxed
> - with us only merging new features when they are ready - so that we
> can trigger a release as needed, as contingency required.
>
> However currently we switched temporarily to a less desirable "we ship
> when it's ready" as the Elasticsearch integration couldn't possibly be
> developed by a single person in a feature branch, so in short we're
> not in a position to "just release" it, as it's not ready and this
> will take another month (optimistically). This would position
> Hibernate Search 5.6 in September.
>
> We'd also want to have WildFly users have a chance to use this new
> Elasticsearch feature, which ties us to make this release compatible
> with ORM 5.0 and 5.1.
>
> So Hibernate ORM 5.2 users who need Hibernate Search will need to wait
> for Search version 5.7, which in timelines would mean this fall.. way
> too far ahead.
>
> (I tried to figure out a way to make Search master compatible with
> both, but that's just not possible: it's either/or, barring an
> outrageous amount of work which I'd rather spend in finishing 5.6 and
> move on do do the migration properly..)
>
> On HSEARCH-2296 [1] James proposed we could already publish a 5.7 SNAPSHOT.
>
> Assuming we can set the right expectations, what would you think of
> this idea to branch a 5.7 already even though 5.6 isn't done?
> We could even call it Alpha1 and tag appropriately. The goal is of
> course to make sure people have at least something they can test with
> and make progress while we put our stuff together.
>
> The downside is of course that all remaining work on 5.6 will have to
> be regularly rebased and applied to 5.7 too. Considering we won't do
> any other changes on 5.7 I don't expect this to hurt too much.
>
> Thanks,
> Sanne
>
> 1 - https://hibernate.atlassian.net/browse/HSEARCH-2296
> ___
> 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] NoORM team meeting minutes

[Guillaume Smet]

Hi all,

Here are the transcripts of the NoORM team meeting:
15:51 < jbott> Ending meeting. Generating minutes. Be patient :)
15:51 < jbott> Meeting ended Tue Aug 16 13:50:25 2016 UTC.
Information about MeetBot at http://wiki.debian.org/MeetBot . (v
0.1.4)
15:51 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-16-13.04.html
15:51 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-16-13.04.txt
15:51 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-16-13.04.log.html

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

Re: [hibernate-dev] [OGM] Bolt vs Rest for Neo4j

[Guillaume Smet]

Hi Davide,

I wanted to add 2 things:
- Neo4j remote with Rest has not been released yet;
- if we remove the Rest protocol, remote Neo4j will only be supported with
Neo4j >= 3

Personally I'm +1 to only support remote Neo4j with Bolt. Maintaining one
more dialect/protocol just to provide remote for Neo4j < 3 does not sound
like a good tradeoff to me.

-- 
Guillaume

On Mon, Aug 22, 2016 at 8:11 PM, Davide D'Alto  wrote:

> Hello,
> at the moment in OGM we connect remotely using the Rest API.
> The reason is that when I created the dialect the new Bolt[1] protocol
> wasn't available.
>
> I've now finished implementing the dialect so that it uses the Bolt
> protocol, there is a lot of duplication since it is very similar to
> the approach I used for Rest.
>
> I worked for a while trying to improve the code but I started to
> wonder if it might be really helpful to provide two ways to connect
> remotely with an increase in complexity of the code (more interfaces
> mainly with some additional classes).
>
> I'm now of the idea that we could remove the dialect thata uses Rest
> and only keep the one that uses Bolt (as suggested by Giulliame in an
> old chat on hipchat).
>
> This will simplify the code and we can always add it back if the need
> arise or somebody asks.
> Note that the Bolt protocol is the suggested one to use for Neo4j
> since it promises better performance.
> It will also allow us to remove some dependencies required for the rest
> client.
>
> Please, let me know if you think there is value in keeping  both
> approaches, otherwise I'm going to send a PR that removes the remote
> one.
>
> Thanks,
> Davide
>
> [1]  https://dzone.com/articles/introducing-bolt-neo4js-
> upcoming-binary-protocol-p
> ___
> 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] Hibernate Validator 5.3.0.CR1 released

[Guillaume Smet]

Hi,

It's with great pleasure that I announce you the first Candidate Release of
Hibernate Validator 5.3.0.

The idea behind this release is to provide our users with enhancements and
bugfixes while we are making progress towards Bean Validation 2.0 and
Hibernate Validator 6.

Expect a quick release of Hibernate Validator 5.3.0.Final if no outstanding
issues are discovered.

See the announcement post
http://in.relation.to/2016/09/05/hibernate-validator-530-cr1-out/ for more
information about this release!

As always, your feedback is highly welcome!

On a side note, if you are interested in defining the future of Bean
Validation, please come join us working on BV 2.0 here:
http://beanvalidation.org/.

Happy testing!

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

[hibernate-dev] NoORM team meeting minutes

[Guillaume Smet]

Hi all,

It just occurred to me this morning that I forgot to send the minutes
of the last NoORM team meeting.

So, here they are:

http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-30-13.00.html
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-30-13.00.txt
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-08-30-13.00.log.html

As for the grouping discussion and concerning the issue with
properties generated by the datastore, the issue is that we need to
flush the pending changes and get the generated values from the
datastore before processing the generated properties (and potentially
putting the entity in the cache).

The 2 proposals to get it working were:
1. when one does a tuple or association read, we check the cache of
operations and flush it if the entity has generated values
2. we call an explicit GridDialect new method when we refresh the
entry to read the generated value

IMHO, 2. was the best option (it's easier to control when the
operations are really executed) so that's what I implemented in the PR
I just posted.

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

[hibernate-dev] [OGM] Issue with a test and the new operation grouping infrastructure

[Guillaume Smet]

Hi,

This is a follow-up of https://github.com/hibernate/hibernate-ogm/pull/767 .

So, in the PR, I commented the following test:
ManyToOneGlobalTest>ManyToOneTest.testRemovalOfTransientEntityWithAssociation
(the "ManyToOneGlobalTest>" part is important)

The test is a Redis one but the issue is a general one.

When running under the ManyToOneGlobalTest umbrella, the associations
are created as separate documents.

The behavior of the test is the following:



=== Creation phase

Create a SalesForce with 2 SalesGuys associated.

The association is managed by SalesGuy.

It creates 4 documents:
SalesForce1
SalesGuy1
SalesGuy2
SalesForce1_SalesGuy navigational information

=== Let's delete the SalesForce1 entity

It removes the SalesForce1 document (note that SalesGuy.salesForce has
a @NotFound(action = NotFoundAction.IGNORE) annotation).

So we end up with having:
SalesGuy1
SalesGuy2
SalesForce1_SalesGuy navigational information [1]

=== Then we delete the 2 SalesGuy

SalesGuys1 removed
-> SalesForce_SalesGuy navigational information updated
SalesGuy2 removed
-> SalesForce1_SalesGuy navigational information removed as it is empty [2]



In [1], we still have the navigational information for SalesForce1 <->
SalesGuys.

With the new grouping infrastructure, I don't save every operation to
the datastore as it's currently done. I have to store the Association
object somewhere to keep track of the association state so I store it
in OgmEntityEntryState in a Map, the key being
the role of the association, just next to the Tuple which has the same
purpose. It works perfectly well except that when we arrive at [2],
the OgmEntityEntryState for SalesForce1 is gone as the entity has been
removed in [1] so I can't access the OgmEntityEntryState of the entity
and so the association document is not removed (and thus the test
fails as it checks there isn't any entity/association left).

Gunnar proposed the idea of storing the inverse Associations in the
OgmEntityEntryState of the association owner. It's indeed one way to
solve the issue.

The issue with this approach is that we need to have the association
owner when we create the AssociationPersister and, while it's not a
problem for most of the cases, I don't see how I can do it in
OgmLoader#getResultSet. I posted a WIP patch here:
https://gist.github.com/gsmet/e18ccb7d3f3494bb334647e540d0d4d0.

Opinions, thoughts?

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

[hibernate-dev] NoORM team meeting minutes

[Guillaume Smet]

Hi!

As usual, the NoORM team meeting minutes.

16:26 < jbott> Meeting ended Tue Sep 13 14:25:49 2016 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:26 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-13-13.00.html
16:26 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-13-13.00.txt
16:26 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-13-13.00.log.html

Emmanuel, quick summary of what you missed:
- Organization for the review of the OGM PRs:
. Hot Rod: Gunnar
. Operation grouping: Davide, Yoann, Gunnar (for the overall approach)
. Neo4j Bolt: Guillaume
- Java 9 module:
-> moved to the Friday hangout

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

[hibernate-dev] Hibernate NoORM team meeting transcripts

[Guillaume Smet]

Hi everyone,

Here are the transcripts of this week's NoORM meeting:

16:26 < jbott> Meeting ended Tue Sep 27 14:26:18 2016 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:26 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-27-13.00.html
16:26 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-27-13.00.txt
16:26 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-09-27-13.00.log.html

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

Re: [hibernate-dev] HSEARCH-2358 "fields" attribute in Elasticsearch search results is being ignored

[Guillaume Smet]

Hi Yoann,

On Wed, Sep 28, 2016 at 2:56 PM, Yoann Rodiere  wrote:

> I'd be in favor of 1, which seems more rational to me. It only has one
> downside: if we go on with this approach, Calendar values (and
> ZonedDateTime, ZonedTime, etc.) will have to be stored as String, not as
> Date, since Elasticsearch doesn't store the timezone, just the UTC
> timestamp. We're currently working this around by inspecting the "_source",
> which contains the original timezone (since it's just the raw, originally
> submitted JSON).
>
> What do you think?
>

I'm not sure you completely understood the consequences of storing dates as
strings.

You won't be able to use these sorts of features:
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-datehistogram-aggregation.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-daterange-aggregation.html
which are used very often when dealing with dates.

I don't think storing dates as strings is a viable alternative.

IMHO, the choice is between:
- using _source as we currently do it. I'm not sure allowing people to
directly inject data into Elasticsearch and bypass Hibernate Search is
something we can support in the long run so I think it would be acceptable
if we document that we don't expect people to index documents directly (or
at least that they should carefully follow the HS indexing format - which
looks like an acceptable thing).
- using fields and be aware that we will get back UTC values from
projections on these fields

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

[hibernate-dev] Hibernate Validator 5.3.0.Final is out

[Guillaume Smet]

Hi,

It's with great pleasure that I announce you the release of the final
version of Hibernate Validator 5.3.0.

There is a lot of activity on Hibernate Validator these days and we decided
to bring to the users several enhancements and bugfixes while we are making
progress towards Bean Validation 2.0 and Hibernate Validator 6.

See the announcement post
http://in.relation.to/2016/10/11/hibernate-validator-530-final-out/ for
more information about the release!

On a side note, if you are interested in defining the future of Bean
Validation, please come join us working on BV 2.0 here:
http://beanvalidation.org/.

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

Re: [hibernate-dev] [OGM] Neo4j integration dependencies

[Guillaume Smet]

On Wed, Oct 19, 2016 at 11:59 AM, Sanne Grinovero 
wrote:

> On 19 October 2016 at 10:44, Yoann Rodiere  wrote:
> > About backward compatibility, I guess there are two options:
> >
> >- If the last released version of the artifact used to contain only
> the
> >embedded mode, we can use maven relocation
> >- Otherwise, we can advertise this artifact as deprecated, remove
> almost
> >everything in it and add the relevant new artifacts as dependencies.
> >
> > Or am I being too naive?
>
> Seems very reasonable. Maybe I'm naive too :)
>

Personally, as it does not sound like a good idea for users to keep the
dependency on the aggregated dependency, I would simply break it and had a
prominent note in the migration notes and in the release announcement.

I think it's also a good way to advertise the new possibility of using
Neo4j as remote and make the users choose the best solution for them.

>From my experience maintaining applications for years, I always prefer to
migrate early to the right solution when there is a compelling reason to do
so and a clear logic in it.

And +1 for the 3 different artifacts.

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

[hibernate-dev] Hibernate Validator 5.3.1.Final is out

[Guillaume Smet]

Hi,

I'm pleased to announce the first maintenance release of Hibernate
Validator 5.3.

For more information, please see the full announcement here:
http://in.relation.to/2016/10/27/hibernate-validator-531-final-out/ .

Have a nice day!

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

Re: [hibernate-dev] Hibernate Search and Elasticsearch 5 support

[Guillaume Smet]

Hi!

On Wed, Nov 2, 2016 at 12:38 PM, Yoann Rodiere  wrote:

>- And, perhaps most importantly, support for defining analyzers in
>elasticsearch.yml has been dropped. This means users have to resort to
> the
>index settings API to define their analyzers. So this breaks our
> automatic
>index creation / mapping generation feature: we put mappings just after
>creating the index, but since the index was just created analyzer
>definitions will be missing and the mapping will be rejected. See
>HSEARCH-2434 (in the comments) for details.
>

The other important point (mentioned in the issue but I think it's
important to outline it here) concerning the analyzers is that they are now
defined per index: there are no global analyzers, you have to define them
for every index using the analyzer. It is totally different from our
current approach and make defining them manually (and maintaining them)
even more cumbersome. Thus I don't think we can consider defining them
manually as an option.

If we want to support Es 5, we need to provide a way to define these
analyzers in HS and make HS post them to Es.

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

[hibernate-dev] Hibernate NoORM IRC meeting minutes

[Guillaume Smet]

Hi!

As usual, the minutes of our regular IRC meeting:
16:17 < jbott> Ending meeting. Generating minutes. Be patient :)
16:17 < jbott> Meeting ended Tue Nov  8 15:17:12 2016 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:17 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-08-14.03.html
16:17 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-08-14.03.txt
16:17 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-08-14.03.log.html

Most notably a discussion on HS and ES 5 support.

Cheers,

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

[hibernate-dev] Hibernate Validator 5.3.2.Final is out

[Guillaume Smet]

Hi,

I'm pleased to announce the second maintenance release of Hibernate
Validator 5.3.

For more information, please see the full announcement here:
http://in.relation.to/2016/11/10/hibernate-validator-532-final-out/ .

Have a nice day!

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

Re: [hibernate-dev] [OGM] Inheritance mapping in Neo4j

[Guillaume Smet]

Hi,

As I understand it, having 2 labels means that you could search either with
n:Person or n:Player?

Thus if we keep the DTYPE: Player in place in addition to both labels, we
won't break anything, will we?

-- 
Guillaume

On Thu, Nov 17, 2016 at 2:30 PM, Sanne Grinovero 
wrote:

> Hi, it makes sense but I don't think we can change the mapping now.
>
> Could you do it as a new option? Would you be able to adjust the
> queries as needed?
>
> If you can make it a configuration property, default to the old style
> mapping, and log a warning of using a deprecated mapping when the old
> one is being used. This implies that people not choosing any mapping
> style explicitly will see a warning (as the old one would still be the
> default).
>
> Thanks,
> Sanne
>
> On 16 November 2016 at 12:42, Davide D'Alto  wrote:
> > A user created the issue https://hibernate.atlassian.net/browse/OGM-1210
> >
> > The problem is that when we use the SingleTable strategy in Neo4j  we
> > add a property DTYPE to the node to discriminate the entities instead
> > of using labels.
> >
> > As an example, given an entity Player that extends Person we create:
> >
> > (n:Person {DTYPE: Player})
> >
> > instead of having a node with two labels:
> >
> > (n:Person:Player)
> >
> > I think the mapping with multiple labels is more natural than the one
> > we currently have.
> >
> > I was wondering if we should fix this for the next release, the
> > problem is that I would need additional information in one of our
> > .spi.*Context and it will change the mapping.
> >
> > The next release should be 5.1.Beta2
> >
> > What do you think?
> >
> > Thanks,
> > Davide
> > ___
> > 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

[hibernate-dev] Hibernate NoORM IRC meeting minutes

[Guillaume Smet]

Hi,

Here are the minutes of this week's NoORM meeting:

16:28 < jbott> Meeting ended Tue Nov 22 15:27:44 2016 UTC.  Information
about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
16:28 < jbott> Minutes:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-22-14.00.html
16:28 < jbott> Minutes (text):
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-22-14.00.txt
16:28 < jbott> Log:
http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2016/hibernate-dev.2016-11-22-14.00.log.html

Cheers,

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