[hibernate-dev] [HSEARCH] Geo queries in ElasticSearch
This morning I was reading http://hashmade.fr/elastic-search-geo-distance-search-with-sorted-and-faceted-results-using-java-native-api/ And the code https://github.com/jsebrien/elastic-search-tests I have to say that we compare quite well in number of lines of code and readability. Considering that ElasticSearch is considered the easy tool / API in the search space, I did not expect that. We could do better on the facet side, I particular to retrieve the facet data. By the way, they offer a way to facet by spatial distance, Hardy, Nicolas, how hard would it be to do the same? Emmanuel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Code style and whitespaces
Looking at the following patch:
}
-catch (IllegalArgumentException e) {
+catch ( IllegalArgumentException e ) {
would you consider it an improvement in terms of consistency with the
Hibernate style?
It has always been my interpretation that we use whitespaces inside
blocks, like:
if ( condition)
//rather than
if (condition)
but we don't for constructor invocations:
new Wrapper(type, param);
//rather than
new Wrapper( type, param );
and we also do not (usually) for catch.
I know that might sound like inconsistent, but the point is
readability: I've got used to it and I could swear that the *different
treating* helps with eyeball code scanning.. but I realize that could
be a very personal opinion.
So since we're encoding this rule now in checkstyle, which one shall
it be for the catch statements?
My guts vote goes to
}
catch (IllegalArgumentException e) {
...
but I'd prefer to follow the convention from ORM, if you guys have a
clear rule :-)
Cheers,
Sanne
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSEARCH] Geo queries in ElasticSearch
Was is demonstrated here has nothing of a facet : these are only aggregates. GeoDistanceFacet results: - Distance from origin: 0.0 Distance to requested: 1000.0 Number of results: 29 Minimum distance: 0.0 Maximum distance: 899.5358131385483 Sum of distances: 17320.209230844222 Mean distance: 597.2485941670421 I see nothing we cannot do. Niko 2013/7/3 Emmanuel Bernard : > This morning I was reading > http://hashmade.fr/elastic-search-geo-distance-search-with-sorted-and-faceted-results-using-java-native-api/ > And the code https://github.com/jsebrien/elastic-search-tests > > I have to say that we compare quite well in number of lines of code and > readability. Considering that ElasticSearch is considered the easy tool / API > in the search space, I did not expect that. > > We could do better on the facet side, I particular to retrieve the facet data. > > By the way, they offer a way to facet by spatial distance, Hardy, Nicolas, > how hard would it be to do the same? > > Emmanuel > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] [OGM] Package structure in OGM modules
Hi,
I'm wondering about the package structure in the provider-specific OGM
modules (hibernate-ogm-mongodb etc.). Why is it e.g.:
org.hibernate.ogm.{datastore|dialect|type|...}.mongodb
instead of
org.hibernate.ogm.mongodb.{datastore|dialect|type|...}
?
Intuitively I'd have expected the latter, as I'd consider the provider as
the more global concept and the different sub-structures of a given
provider as a more specific (sub)-concept.
It surely works both ways, I'm just wondering what the rationale was to go
for the current approach.
Thanks,
--Gunnar
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] new "releases" feature in GitHub
how does it help with announcements? On 3 Jul 2013 04:23, "Brett Meyer" wrote: > https://github.com/blog/1547-release-your-software > > This looks pretty useful -- download links, release notes, etc. Use it in > place of announcements on in.relation.to? ;) > > Brett Meyer > Red Hat Software Engineer, Hibernate > ___ > 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] Code style and whitespaces
+1 for 'catch ( IllegalArgumentException e )' - using white spaces
On 3 Jan 2013, at 11:07 AM, Sanne Grinovero wrote:
> Looking at the following patch:
>
>
> }
> -catch (IllegalArgumentException e) {
> +catch ( IllegalArgumentException e ) {
>
> would you consider it an improvement in terms of consistency with the
> Hibernate style?
>
> It has always been my interpretation that we use whitespaces inside
> blocks, like:
>
>
> if ( condition)
> //rather than
> if (condition)
>
> but we don't for constructor invocations:
>
> new Wrapper(type, param);
> //rather than
> new Wrapper( type, param );
>
> and we also do not (usually) for catch.
>
> I know that might sound like inconsistent, but the point is
> readability: I've got used to it and I could swear that the *different
> treating* helps with eyeball code scanning.. but I realize that could
> be a very personal opinion.
>
> So since we're encoding this rule now in checkstyle, which one shall
> it be for the catch statements?
>
> My guts vote goes to
>
> }
> catch (IllegalArgumentException e) {
> ...
>
> but I'd prefer to follow the convention from ORM, if you guys have a
> clear rule :-)
>
> 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] [HSEARCH] Geo queries in ElasticSearch
I'm more interested in something like Within 10 kms (23) Between 10 and 50 kms (45) Above 50 kms (75) On Wed 2013-07-03 11:24, Nicolas Helleringer wrote: > Was is demonstrated here has nothing of a facet : these are only aggregates. > > > GeoDistanceFacet results: > - > Distance from origin: 0.0 > Distance to requested: 1000.0 > Number of results: 29 > Minimum distance: 0.0 > Maximum distance: 899.5358131385483 > Sum of distances: 17320.209230844222 > Mean distance: 597.2485941670421 > > > I see nothing we cannot do. > > Niko > > 2013/7/3 Emmanuel Bernard : > > This morning I was reading > > http://hashmade.fr/elastic-search-geo-distance-search-with-sorted-and-faceted-results-using-java-native-api/ > > And the code https://github.com/jsebrien/elastic-search-tests > > > > I have to say that we compare quite well in number of lines of code and > > readability. Considering that ElasticSearch is considered the easy tool / > > API in the search space, I did not expect that. > > > > We could do better on the facet side, I particular to retrieve the facet > > data. > > > > By the way, they offer a way to facet by spatial distance, Hardy, Nicolas, > > how hard would it be to do the same? > > > > Emmanuel > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Package structure in OGM modules
It grew with a similar package structure han ORM but that can be
revisited. In fact there are many package changes we need to do (api /
spi / impl split etc) but these are not important for now.
On Wed 2013-07-03 11:34, Gunnar Morling wrote:
> Hi,
>
> I'm wondering about the package structure in the provider-specific OGM
> modules (hibernate-ogm-mongodb etc.). Why is it e.g.:
>
> org.hibernate.ogm.{datastore|dialect|type|...}.mongodb
>
> instead of
>
> org.hibernate.ogm.mongodb.{datastore|dialect|type|...}
>
> ?
>
> Intuitively I'd have expected the latter, as I'd consider the provider as
> the more global concept and the different sub-structures of a given
> provider as a more specific (sub)-concept.
>
> It surely works both ways, I'm just wondering what the rationale was to go
> for the current approach.
>
> Thanks,
>
> --Gunnar
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSEARCH] Geo queries in ElasticSearch
The difficulty in this is that unlike other facets counts those are to be dynamically computed. The current facet systems (either native Lucene or Hibernate ones) are using the Lucen Token reverse indexes performance to compute the facets on queries results that can be very large. This cannot be done here as the distance to the search center is dynamic. If you have a query with 10k result and you display only the first ten results as first page and to strengthen the search you want geo facets then you have to compute distance on all the 10k results to produce that. On the performance PoV this will fail. Niko 2013/7/3 Emmanuel Bernard : > I'm more interested in something like > > Within 10 kms (23) > Between 10 and 50 kms (45) > Above 50 kms (75) > > > On Wed 2013-07-03 11:24, Nicolas Helleringer wrote: >> Was is demonstrated here has nothing of a facet : these are only aggregates. >> >> >> GeoDistanceFacet results: >> - >> Distance from origin: 0.0 >> Distance to requested: 1000.0 >> Number of results: 29 >> Minimum distance: 0.0 >> Maximum distance: 899.5358131385483 >> Sum of distances: 17320.209230844222 >> Mean distance: 597.2485941670421 >> >> >> I see nothing we cannot do. >> >> Niko >> >> 2013/7/3 Emmanuel Bernard : >> > This morning I was reading >> > http://hashmade.fr/elastic-search-geo-distance-search-with-sorted-and-faceted-results-using-java-native-api/ >> > And the code https://github.com/jsebrien/elastic-search-tests >> > >> > I have to say that we compare quite well in number of lines of code and >> > readability. Considering that ElasticSearch is considered the easy tool / >> > API in the search space, I did not expect that. >> > >> > We could do better on the facet side, I particular to retrieve the facet >> > data. >> > >> > By the way, they offer a way to facet by spatial distance, Hardy, Nicolas, >> > how hard would it be to do the same? >> > >> > Emmanuel >> > ___ >> > hibernate-dev mailing list >> > hibernate-dev@lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSEARCH] Geo queries in ElasticSearch
Can you then also easily (aka really fast) know which are those points -- even with really big number of data? On Jul 3, 2013, at 2:14 PM, Emmanuel Bernard wrote: > I'm more interested in something like > > Within 10 kms (23) > Between 10 and 50 kms (45) > Above 50 kms (75) > > > On Wed 2013-07-03 11:24, Nicolas Helleringer wrote: >> Was is demonstrated here has nothing of a facet : these are only aggregates. >> >> >> GeoDistanceFacet results: >> - >> Distance from origin: 0.0 >> Distance to requested: 1000.0 >> Number of results: 29 >> Minimum distance: 0.0 >> Maximum distance: 899.5358131385483 >> Sum of distances: 17320.209230844222 >> Mean distance: 597.2485941670421 >> >> >> I see nothing we cannot do. >> >> Niko >> >> 2013/7/3 Emmanuel Bernard : >>> This morning I was reading >>> http://hashmade.fr/elastic-search-geo-distance-search-with-sorted-and-faceted-results-using-java-native-api/ >>> And the code https://github.com/jsebrien/elastic-search-tests >>> >>> I have to say that we compare quite well in number of lines of code and >>> readability. Considering that ElasticSearch is considered the easy tool / >>> API in the search space, I did not expect that. >>> >>> We could do better on the facet side, I particular to retrieve the facet >>> data. >>> >>> By the way, they offer a way to facet by spatial distance, Hardy, Nicolas, >>> how hard would it be to do the same? >>> >>> Emmanuel >>> ___ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Code style and whitespaces
There is a mix in ORM as well. My vote is for no spaces inside the parens
for catch statements. I do like the spaces for if, for, while, etc though.
On Jul 3, 2013 5:29 AM, "Hardy Ferentschik" wrote:
> +1 for 'catch ( IllegalArgumentException e )' - using white spaces
>
> On 3 Jan 2013, at 11:07 AM, Sanne Grinovero wrote:
>
> > Looking at the following patch:
> >
> >
> > }
> > -catch (IllegalArgumentException e) {
> > +catch ( IllegalArgumentException e ) {
> >
> > would you consider it an improvement in terms of consistency with the
> > Hibernate style?
> >
> > It has always been my interpretation that we use whitespaces inside
> > blocks, like:
> >
> >
> > if ( condition)
> > //rather than
> > if (condition)
> >
> > but we don't for constructor invocations:
> >
> > new Wrapper(type, param);
> > //rather than
> > new Wrapper( type, param );
> >
> > and we also do not (usually) for catch.
> >
> > I know that might sound like inconsistent, but the point is
> > readability: I've got used to it and I could swear that the *different
> > treating* helps with eyeball code scanning.. but I realize that could
> > be a very personal opinion.
> >
> > So since we're encoding this rule now in checkstyle, which one shall
> > it be for the catch statements?
> >
> > My guts vote goes to
> >
> > }
> > catch (IllegalArgumentException e) {
> > ...
> >
> > but I'd prefer to follow the convention from ORM, if you guys have a
> > clear rule :-)
> >
> > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Code style and whitespaces
I'm voting for having white spaces in catch as well as constructor
invocations, the reason being to ensure a consistent style with method
invocations, if, while etc. I don't see an advantage in having white space
in some of these constructs but not in others.
2013/7/3 Steve Ebersole
> There is a mix in ORM as well. My vote is for no spaces inside the parens
> for catch statements. I do like the spaces for if, for, while, etc though.
> On Jul 3, 2013 5:29 AM, "Hardy Ferentschik" wrote:
>
> > +1 for 'catch ( IllegalArgumentException e )' - using white spaces
> >
> > On 3 Jan 2013, at 11:07 AM, Sanne Grinovero wrote:
> >
> > > Looking at the following patch:
> > >
> > >
> > > }
> > > -catch (IllegalArgumentException e) {
> > > +catch ( IllegalArgumentException e ) {
> > >
> > > would you consider it an improvement in terms of consistency with the
> > > Hibernate style?
> > >
> > > It has always been my interpretation that we use whitespaces inside
> > > blocks, like:
> > >
> > >
> > > if ( condition)
> > > //rather than
> > > if (condition)
> > >
> > > but we don't for constructor invocations:
> > >
> > > new Wrapper(type, param);
> > > //rather than
> > > new Wrapper( type, param );
> > >
> > > and we also do not (usually) for catch.
> > >
> > > I know that might sound like inconsistent, but the point is
> > > readability: I've got used to it and I could swear that the *different
> > > treating* helps with eyeball code scanning.. but I realize that could
> > > be a very personal opinion.
> > >
> > > So since we're encoding this rule now in checkstyle, which one shall
> > > it be for the catch statements?
> > >
> > > My guts vote goes to
> > >
> > > }
> > > catch (IllegalArgumentException e) {
> > > ...
> > >
> > > but I'd prefer to follow the convention from ORM, if you guys have a
> > > clear rule :-)
> > >
> > > 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
> >
> ___
> 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] [OGM] Package structure in OGM modules
I have created https://hibernate.atlassian.net/browse/OGM-292 to capture
this.
On Wed 2013-07-03 14:17, Emmanuel Bernard wrote:
> It grew with a similar package structure han ORM but that can be
> revisited. In fact there are many package changes we need to do (api /
> spi / impl split etc) but these are not important for now.
>
> On Wed 2013-07-03 11:34, Gunnar Morling wrote:
> > Hi,
> >
> > I'm wondering about the package structure in the provider-specific OGM
> > modules (hibernate-ogm-mongodb etc.). Why is it e.g.:
> >
> > org.hibernate.ogm.{datastore|dialect|type|...}.mongodb
> >
> > instead of
> >
> > org.hibernate.ogm.mongodb.{datastore|dialect|type|...}
> >
> > ?
> >
> > Intuitively I'd have expected the latter, as I'd consider the provider as
> > the more global concept and the different sub-structures of a given
> > provider as a more specific (sub)-concept.
> >
> > It surely works both ways, I'm just wondering what the rationale was to go
> > for the current approach.
> >
> > Thanks,
> >
> > --Gunnar
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [OGM] Package structure in OGM modules
2013/7/3 Emmanuel Bernard
> I have created https://hibernate.atlassian.net/browse/OGM-292 to capture
> this.
>
Cool, thanks.
As you say, a proper api/spi/impl split is even more important in order to
avoid breaking changes for clients later on.
> On Wed 2013-07-03 14:17, Emmanuel Bernard wrote:
> > It grew with a similar package structure han ORM but that can be
> > revisited. In fact there are many package changes we need to do (api /
> > spi / impl split etc) but these are not important for now.
> >
> > On Wed 2013-07-03 11:34, Gunnar Morling wrote:
> > > Hi,
> > >
> > > I'm wondering about the package structure in the provider-specific OGM
> > > modules (hibernate-ogm-mongodb etc.). Why is it e.g.:
> > >
> > > org.hibernate.ogm.{datastore|dialect|type|...}.mongodb
> > >
> > > instead of
> > >
> > > org.hibernate.ogm.mongodb.{datastore|dialect|type|...}
> > >
> > > ?
> > >
> > > Intuitively I'd have expected the latter, as I'd consider the provider
> as
> > > the more global concept and the different sub-structures of a given
> > > provider as a more specific (sub)-concept.
> > >
> > > It surely works both ways, I'm just wondering what the rationale was
> to go
> > > for the current approach.
> > >
> > > Thanks,
> > >
> > > --Gunnar
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSEARCH] Geo queries in ElasticSearch
It seems to me that for each geo facet, you need to execute a query which is fast. So in my example, the query will be executed 4 times. One for the regular query and 3 times with different radius retrieving the count. In other words, you don't really need to compute the distance for each point. Wouldn't that work? Emmanuel On Wed 2013-07-03 14:21, Nicolas Helleringer wrote: > The difficulty in this is that unlike other facets counts those are to > be dynamically computed. > > The current facet systems (either native Lucene or Hibernate ones) are > using the Lucen Token reverse > indexes performance to compute the facets on queries results that can > be very large. > > This cannot be done here as the distance to the search center is dynamic. > If you have a query with 10k result and you display only the first ten > results as first page and to strengthen > the search you want geo facets then you have to compute distance on > all the 10k results to produce that. > On the performance PoV this will fail. > > Niko > > > 2013/7/3 Emmanuel Bernard : > > I'm more interested in something like > > > > Within 10 kms (23) > > Between 10 and 50 kms (45) > > Above 50 kms (75) > > > > > > On Wed 2013-07-03 11:24, Nicolas Helleringer wrote: > >> Was is demonstrated here has nothing of a facet : these are only > >> aggregates. > >> > >> > >> GeoDistanceFacet results: > >> - > >> Distance from origin: 0.0 > >> Distance to requested: 1000.0 > >> Number of results: 29 > >> Minimum distance: 0.0 > >> Maximum distance: 899.5358131385483 > >> Sum of distances: 17320.209230844222 > >> Mean distance: 597.2485941670421 > >> > >> > >> I see nothing we cannot do. > >> > >> Niko > >> > >> 2013/7/3 Emmanuel Bernard : > >> > This morning I was reading > >> > http://hashmade.fr/elastic-search-geo-distance-search-with-sorted-and-faceted-results-using-java-native-api/ > >> > And the code https://github.com/jsebrien/elastic-search-tests > >> > > >> > I have to say that we compare quite well in number of lines of code and > >> > readability. Considering that ElasticSearch is considered the easy tool > >> > / API in the search space, I did not expect that. > >> > > >> > We could do better on the facet side, I particular to retrieve the facet > >> > data. > >> > > >> > By the way, they offer a way to facet by spatial distance, Hardy, > >> > Nicolas, how hard would it be to do the same? > >> > > >> > Emmanuel > >> > ___ > >> > hibernate-dev mailing list > >> > hibernate-dev@lists.jboss.org > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Code style and whitespaces
The "original" rule was that parens should always be separated by spaces.
E.g.:
if (isTrue ()) { ... }
Is clearly fugly.
if ( isTrue () ) { ... }
To me is clearly more readable.
Method/constructor declarations do not use spaces inside parens simply
because the arguments list cannot contain parens. Same for exception
catching btw..
On Jul 3, 2013 7:31 AM, "Gunnar Morling" wrote:
> I'm voting for having white spaces in catch as well as constructor
> invocations, the reason being to ensure a consistent style with method
> invocations, if, while etc. I don't see an advantage in having white space
> in some of these constructs but not in others.
>
>
> 2013/7/3 Steve Ebersole
>
>> There is a mix in ORM as well. My vote is for no spaces inside the parens
>> for catch statements. I do like the spaces for if, for, while, etc
>> though.
>> On Jul 3, 2013 5:29 AM, "Hardy Ferentschik" wrote:
>>
>> > +1 for 'catch ( IllegalArgumentException e )' - using white spaces
>> >
>> > On 3 Jan 2013, at 11:07 AM, Sanne Grinovero
>> wrote:
>> >
>> > > Looking at the following patch:
>> > >
>> > >
>> > > }
>> > > -catch (IllegalArgumentException e) {
>> > > +catch ( IllegalArgumentException e ) {
>> > >
>> > > would you consider it an improvement in terms of consistency with the
>> > > Hibernate style?
>> > >
>> > > It has always been my interpretation that we use whitespaces inside
>> > > blocks, like:
>> > >
>> > >
>> > > if ( condition)
>> > > //rather than
>> > > if (condition)
>> > >
>> > > but we don't for constructor invocations:
>> > >
>> > > new Wrapper(type, param);
>> > > //rather than
>> > > new Wrapper( type, param );
>> > >
>> > > and we also do not (usually) for catch.
>> > >
>> > > I know that might sound like inconsistent, but the point is
>> > > readability: I've got used to it and I could swear that the *different
>> > > treating* helps with eyeball code scanning.. but I realize that could
>> > > be a very personal opinion.
>> > >
>> > > So since we're encoding this rule now in checkstyle, which one shall
>> > > it be for the catch statements?
>> > >
>> > > My guts vote goes to
>> > >
>> > > }
>> > > catch (IllegalArgumentException e) {
>> > > ...
>> > >
>> > > but I'd prefer to follow the convention from ORM, if you guys have a
>> > > clear rule :-)
>> > >
>> > > 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
>> >
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSEARCH] Geo queries in ElasticSearch
Good point. It might be worth a try =) Niko 2013/7/3 Emmanuel Bernard : > It seems to me that for each geo facet, you need to execute a query > which is fast. So in my example, the query will be executed 4 times. One > for the regular query and 3 times with different radius retrieving the > count. In other words, you don't really need to compute the distance for > each point. > > Wouldn't that work? > > Emmanuel > > On Wed 2013-07-03 14:21, Nicolas Helleringer wrote: >> The difficulty in this is that unlike other facets counts those are to >> be dynamically computed. >> >> The current facet systems (either native Lucene or Hibernate ones) are >> using the Lucen Token reverse >> indexes performance to compute the facets on queries results that can >> be very large. >> >> This cannot be done here as the distance to the search center is dynamic. >> If you have a query with 10k result and you display only the first ten >> results as first page and to strengthen >> the search you want geo facets then you have to compute distance on >> all the 10k results to produce that. >> On the performance PoV this will fail. >> >> Niko >> >> >> 2013/7/3 Emmanuel Bernard : >> > I'm more interested in something like >> > >> > Within 10 kms (23) >> > Between 10 and 50 kms (45) >> > Above 50 kms (75) >> > >> > >> > On Wed 2013-07-03 11:24, Nicolas Helleringer wrote: >> >> Was is demonstrated here has nothing of a facet : these are only >> >> aggregates. >> >> >> >> >> >> GeoDistanceFacet results: >> >> - >> >> Distance from origin: 0.0 >> >> Distance to requested: 1000.0 >> >> Number of results: 29 >> >> Minimum distance: 0.0 >> >> Maximum distance: 899.5358131385483 >> >> Sum of distances: 17320.209230844222 >> >> Mean distance: 597.2485941670421 >> >> >> >> >> >> I see nothing we cannot do. >> >> >> >> Niko >> >> >> >> 2013/7/3 Emmanuel Bernard : >> >> > This morning I was reading >> >> > http://hashmade.fr/elastic-search-geo-distance-search-with-sorted-and-faceted-results-using-java-native-api/ >> >> > And the code https://github.com/jsebrien/elastic-search-tests >> >> > >> >> > I have to say that we compare quite well in number of lines of code and >> >> > readability. Considering that ElasticSearch is considered the easy tool >> >> > / API in the search space, I did not expect that. >> >> > >> >> > We could do better on the facet side, I particular to retrieve the >> >> > facet data. >> >> > >> >> > By the way, they offer a way to facet by spatial distance, Hardy, >> >> > Nicolas, how hard would it be to do the same? >> >> > >> >> > Emmanuel >> >> > ___ >> >> > hibernate-dev mailing list >> >> > hibernate-dev@lists.jboss.org >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Code style and whitespaces
On 3 Jan 2013, at 2:36 PM, Steve Ebersole wrote:
> The "original" rule was that parens should always be separated by spaces.
> E.g.:
>
> if (isTrue ()) { ... }
>
> Is clearly fugly.
>
> if ( isTrue () ) { ... }
>
> To me is clearly more readable.
Sure, I agree on you on that
> Method/constructor declarations do not use spaces inside parens simply
> because the arguments list cannot contain parens. Same for exception
> catching btw..
But does that mean that you should not use spaces. Does it become less readable
to use 'catch ( IllegalArgumentException e )' instead of 'catch
(IllegalArgumentException e)'?
As Gunnar is saying, for consistency reason it would make sense to apply spaces
in this case as well.
My 0.02$
--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Code style and whitespaces
2013/7/3 Steve Ebersole
> The "original" rule was that parens should always be separated by spaces.
> E.g.:
>
> if (isTrue ()) { ... }
>
> Is clearly fugly.
>
> if ( isTrue () ) { ... }
>
> To me is clearly more readable.
>
> Method/constructor declarations do not use spaces inside parens simply
> because the arguments list cannot contain parens. Same for exception
> catching btw..
>
Ah, I see. This reasoning makes sense, but IMO the rule is not really
apparent, I guess one just needs to know it. I don't really mind either
way, but at least method invocations and constructor invocations should be
handled consistently (i.e. both with white space following the reasoning
above).
> On Jul 3, 2013 7:31 AM, "Gunnar Morling" wrote:
>
>> I'm voting for having white spaces in catch as well as constructor
>> invocations, the reason being to ensure a consistent style with method
>> invocations, if, while etc. I don't see an advantage in having white space
>> in some of these constructs but not in others.
>>
>>
>> 2013/7/3 Steve Ebersole
>>
>>> There is a mix in ORM as well. My vote is for no spaces inside the
>>> parens
>>> for catch statements. I do like the spaces for if, for, while, etc
>>> though.
>>> On Jul 3, 2013 5:29 AM, "Hardy Ferentschik" wrote:
>>>
>>> > +1 for 'catch ( IllegalArgumentException e )' - using white spaces
>>> >
>>> > On 3 Jan 2013, at 11:07 AM, Sanne Grinovero
>>> wrote:
>>> >
>>> > > Looking at the following patch:
>>> > >
>>> > >
>>> > > }
>>> > > -catch (IllegalArgumentException e) {
>>> > > +catch ( IllegalArgumentException e ) {
>>> > >
>>> > > would you consider it an improvement in terms of consistency with the
>>> > > Hibernate style?
>>> > >
>>> > > It has always been my interpretation that we use whitespaces inside
>>> > > blocks, like:
>>> > >
>>> > >
>>> > > if ( condition)
>>> > > //rather than
>>> > > if (condition)
>>> > >
>>> > > but we don't for constructor invocations:
>>> > >
>>> > > new Wrapper(type, param);
>>> > > //rather than
>>> > > new Wrapper( type, param );
>>> > >
>>> > > and we also do not (usually) for catch.
>>> > >
>>> > > I know that might sound like inconsistent, but the point is
>>> > > readability: I've got used to it and I could swear that the
>>> *different
>>> > > treating* helps with eyeball code scanning.. but I realize that could
>>> > > be a very personal opinion.
>>> > >
>>> > > So since we're encoding this rule now in checkstyle, which one shall
>>> > > it be for the catch statements?
>>> > >
>>> > > My guts vote goes to
>>> > >
>>> > > }
>>> > > catch (IllegalArgumentException e) {
>>> > > ...
>>> > >
>>> > > but I'd prefer to follow the convention from ORM, if you guys have a
>>> > > clear rule :-)
>>> > >
>>> > > 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
>>> >
>>> ___
>>> 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] Code style and whitespaces
Well you assume it is consistent, which I agree is the important point it
determining whether to make this a rule. So let's examine that...
Would you also agree that this is better:
private void doIt (String it) { ... }
than:
private void doIt ( String it ) { ... }
?
Which ruleset should catch statements belong?
On Jul 3, 2013 7:41 AM, "Hardy Ferentschik" wrote:
>
> On 3 Jan 2013, at 2:36 PM, Steve Ebersole wrote:
>
> > The "original" rule was that parens should always be separated by
> spaces. E.g.:
> >
> > if (isTrue ()) { ... }
> >
> > Is clearly fugly.
> >
> > if ( isTrue () ) { ... }
> >
> > To me is clearly more readable.
>
> Sure, I agree on you on that
>
> > Method/constructor declarations do not use spaces inside parens simply
> because the arguments list cannot contain parens. Same for exception
> catching btw..
>
> But does that mean that you should not use spaces. Does it become less
> readable to use 'catch ( IllegalArgumentException e )' instead of 'catch
> (IllegalArgumentException e)'?
> As Gunnar is saying, for consistency reason it would make sense to apply
> spaces in this case as well.
>
> My 0.02$
>
> --Hardy
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSEARCH] Geo queries in ElasticSearch
I did not get your point Ales : Hibernate Search does support geo queries since 4.2 (early 2013) so yes you can know which points are in a certain distance event with big number of data. The challenge for geo facets is to do this many times (as many times as they are defined ranges) as automatically as possible. Niko 2013/7/3 Ales Justin : > Can you then also easily (aka really fast) know which are those points -- > even with really big number of data? > > On Jul 3, 2013, at 2:14 PM, Emmanuel Bernard wrote: > >> I'm more interested in something like >> >> Within 10 kms (23) >> Between 10 and 50 kms (45) >> Above 50 kms (75) >> >> >> On Wed 2013-07-03 11:24, Nicolas Helleringer wrote: >>> Was is demonstrated here has nothing of a facet : these are only aggregates. >>> >>> >>> GeoDistanceFacet results: >>> - >>> Distance from origin: 0.0 >>> Distance to requested: 1000.0 >>> Number of results: 29 >>> Minimum distance: 0.0 >>> Maximum distance: 899.5358131385483 >>> Sum of distances: 17320.209230844222 >>> Mean distance: 597.2485941670421 >>> >>> >>> I see nothing we cannot do. >>> >>> Niko >>> >>> 2013/7/3 Emmanuel Bernard : This morning I was reading http://hashmade.fr/elastic-search-geo-distance-search-with-sorted-and-faceted-results-using-java-native-api/ And the code https://github.com/jsebrien/elastic-search-tests I have to say that we compare quite well in number of lines of code and readability. Considering that ElasticSearch is considered the easy tool / API in the search space, I did not expect that. We could do better on the facet side, I particular to retrieve the facet data. By the way, they offer a way to facet by spatial distance, Hardy, Nicolas, how hard would it be to do the same? Emmanuel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev >> ___ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Code style and whitespaces
Well the trouble is that the "don't double up parens without spaces" rule
does not exist. I guess you and Davide could tackle that with y'alls
regex-fu though :)
Tbh for me I think we should be looking at long parameter lists, both in
terms if validating their use and how they are expressed. We have lots of
mixed styles there in ORM code.
On Jul 3, 2013 7:52 AM, "Gunnar Morling" wrote:
> 2013/7/3 Steve Ebersole
>
>> The "original" rule was that parens should always be separated by
>> spaces. E.g.:
>>
>> if (isTrue ()) { ... }
>>
>> Is clearly fugly.
>>
>> if ( isTrue () ) { ... }
>>
>> To me is clearly more readable.
>>
>> Method/constructor declarations do not use spaces inside parens simply
>> because the arguments list cannot contain parens. Same for exception
>> catching btw..
>>
> Ah, I see. This reasoning makes sense, but IMO the rule is not really
> apparent, I guess one just needs to know it. I don't really mind either
> way, but at least method invocations and constructor invocations should be
> handled consistently (i.e. both with white space following the reasoning
> above).
>
>
>
>> On Jul 3, 2013 7:31 AM, "Gunnar Morling" wrote:
>>
>>> I'm voting for having white spaces in catch as well as constructor
>>> invocations, the reason being to ensure a consistent style with method
>>> invocations, if, while etc. I don't see an advantage in having white space
>>> in some of these constructs but not in others.
>>>
>>>
>>> 2013/7/3 Steve Ebersole
>>>
There is a mix in ORM as well. My vote is for no spaces inside the
parens
for catch statements. I do like the spaces for if, for, while, etc
though.
On Jul 3, 2013 5:29 AM, "Hardy Ferentschik"
wrote:
> +1 for 'catch ( IllegalArgumentException e )' - using white spaces
>
> On 3 Jan 2013, at 11:07 AM, Sanne Grinovero
wrote:
>
> > Looking at the following patch:
> >
> >
> > }
> > -catch (IllegalArgumentException e) {
> > +catch ( IllegalArgumentException e ) {
> >
> > would you consider it an improvement in terms of consistency with
the
> > Hibernate style?
> >
> > It has always been my interpretation that we use whitespaces inside
> > blocks, like:
> >
> >
> > if ( condition)
> > //rather than
> > if (condition)
> >
> > but we don't for constructor invocations:
> >
> > new Wrapper(type, param);
> > //rather than
> > new Wrapper( type, param );
> >
> > and we also do not (usually) for catch.
> >
> > I know that might sound like inconsistent, but the point is
> > readability: I've got used to it and I could swear that the
*different
> > treating* helps with eyeball code scanning.. but I realize that
could
> > be a very personal opinion.
> >
> > So since we're encoding this rule now in checkstyle, which one shall
> > it be for the catch statements?
> >
> > My guts vote goes to
> >
> > }
> > catch (IllegalArgumentException e) {
> > ...
> >
> > but I'd prefer to follow the convention from ORM, if you guys have a
> > clear rule :-)
> >
> > 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
>
___
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] Code style and whitespaces
On 3 Jan 2013, at 2:52 PM, Steve Ebersole wrote:
> Well you assume it is consistent, which I agree is the important point it
> determining whether to make this a rule. So let's examine that...
>
> Would you also agree that this is better:
>
> private void doIt (String it) { ... }
>
> than:
>
> private void doIt ( String it ) { ... }
>
> ?
>
> Which ruleset should catch statements belong?
I hate when you blast my arguments ;-)
Anyways, as a matter of taste I'd prefer spaces for the catch clause.
--Hardy
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Code style and whitespaces
I vote for having spaces in the method/constructor usages.
Like Gunnar (iirc) said earlier, I find having the usages be consistent and
different from the declarations to be a simple but effective visual clue as
I look through the source.
That's just my feelings though..
On Jul 3, 2013 7:52 AM, "Gunnar Morling" wrote:
> 2013/7/3 Steve Ebersole
>
>> The "original" rule was that parens should always be separated by
>> spaces. E.g.:
>>
>> if (isTrue ()) { ... }
>>
>> Is clearly fugly.
>>
>> if ( isTrue () ) { ... }
>>
>> To me is clearly more readable.
>>
>> Method/constructor declarations do not use spaces inside parens simply
>> because the arguments list cannot contain parens. Same for exception
>> catching btw..
>>
> Ah, I see. This reasoning makes sense, but IMO the rule is not really
> apparent, I guess one just needs to know it. I don't really mind either
> way, but at least method invocations and constructor invocations should be
> handled consistently (i.e. both with white space following the reasoning
> above).
>
>
>
>> On Jul 3, 2013 7:31 AM, "Gunnar Morling" wrote:
>>
>>> I'm voting for having white spaces in catch as well as constructor
>>> invocations, the reason being to ensure a consistent style with method
>>> invocations, if, while etc. I don't see an advantage in having white space
>>> in some of these constructs but not in others.
>>>
>>>
>>> 2013/7/3 Steve Ebersole
>>>
There is a mix in ORM as well. My vote is for no spaces inside the
parens
for catch statements. I do like the spaces for if, for, while, etc
though.
On Jul 3, 2013 5:29 AM, "Hardy Ferentschik"
wrote:
> +1 for 'catch ( IllegalArgumentException e )' - using white spaces
>
> On 3 Jan 2013, at 11:07 AM, Sanne Grinovero
wrote:
>
> > Looking at the following patch:
> >
> >
> > }
> > -catch (IllegalArgumentException e) {
> > +catch ( IllegalArgumentException e ) {
> >
> > would you consider it an improvement in terms of consistency with
the
> > Hibernate style?
> >
> > It has always been my interpretation that we use whitespaces inside
> > blocks, like:
> >
> >
> > if ( condition)
> > //rather than
> > if (condition)
> >
> > but we don't for constructor invocations:
> >
> > new Wrapper(type, param);
> > //rather than
> > new Wrapper( type, param );
> >
> > and we also do not (usually) for catch.
> >
> > I know that might sound like inconsistent, but the point is
> > readability: I've got used to it and I could swear that the
*different
> > treating* helps with eyeball code scanning.. but I realize that
could
> > be a very personal opinion.
> >
> > So since we're encoding this rule now in checkstyle, which one shall
> > it be for the catch statements?
> >
> > My guts vote goes to
> >
> > }
> > catch (IllegalArgumentException e) {
> > ...
> >
> > but I'd prefer to follow the convention from ORM, if you guys have a
> > clear rule :-)
> >
> > 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
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] hibernate-delta
It says ...between your Hibernate config file and your development database... (http://www.liquibase.org/documentation/hibernate.html) It's obvious actually, what else could you compare the hibernate.cfg.xml to. But maybe I should ask the liquibase-hiberante developers if they are interested in the changes. Am 28.06.2013 18:50, schrieb Steve Ebersole: > That's not true. Neither liquibase nor flyway use a connection to the > database. > On Jun 28, 2013 11:22 AM, "Gregor Zeitlinger" > wrote: > >> The tool you mention works against a database connection which is not what >> I want. >> >> Steve Ebersole wrote: >> >>> Tools do exist that do this already. Liquibase and Flyway are 2 I know >>> of. Liquibase even has some support for generating its "change logs" >> >from Hibernate mappings[1]. >>> [1] http://www.liquibase.org/documentation/hibernate.html >>> >>> >>> On Mon 24 Jun 2013 07:20:15 AM CDT, Gregor Zeitlinger wrote: The main difference is that hibernate-delta does NOT run against a live database. I do load the previous version of a mapping from a custom XML file. This enables some scenarios that are not possible with the hibernate build in schemaupdate, such as 1. add a non-null column 2. change the datatype of a column 3. rename a column So the workflow is as follows: 1. Create an entity Customer 2. Run UpdateSqlGenerator (which updates the schema.xml file) 3. Copy the output to a liquibase or Flyway 4. commit and push schema.xml Note that you do not need any database connection for the entire >> workflow. I do like to test it on a scratch dump from the live database when I add a non-null column and fill it with a qeury for example. In addition, we have an automated test that executes changesets and compares the final schema with expected one from the annotations - using hibernate-delta - which in return uses liquibase to read the schema of the updated database. Gregor Am 24.06.2013 11:24, schrieb Max Rydahl Andersen: > Looks interesting - what is the big difference between this and > what the built in schemaupdate does ? > > If you don't look at previous versions of the mapping I would not > expect you to do much better (but if you do that would be the natural > place to contribute it to) > > Do you got an example on how to use this ? > > /max > > On Thu, Jun 20, 2013 at 11:59:51AM +0200, Gregor Zeitlinger wrote: >> Hi, >> >> I've created https://github.com/txtr/hibernate-delta because I >> couldn't >> find a solution that would generate SQL update statements based on the >> fields that I added to my @Entity. >> The trick is that it stores the schema in an XML file that is commited >> to git. That way, you only get the differences you introduced. >> It can also find the differences between your XML schema and the >> actual >> database (using liquibase). >> >> Now the questions >> >> 1. Is this something that already exists? >> 2. Is somebody interested in growing this from the current setup >> (tested with Oracle only)? >> 3. Would this maybe even a candidate to include in hibernate tools? >> >> -- >> Gregor Zeitlinger >> gregor.zeitlin...@txtr.com >> ___ >> 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 -- Gregor Zeitlinger gregor.zeitlin...@txtr.com Notice The information in this message is confidential and may be legally privileged. It is intended solely for the addressee. Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying or distribution of the message, or any action taken by you in reliance on it, is prohibited and may be unlawful. If you have received this message in error, please delete it and contact the sender immediately. Thank you. ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Code style and whitespaces
On 3 Jul 2013 14:06, "Steve Ebersole" wrote:
>
> I vote for having spaces in the method/constructor usages.
I'm not seeing the need for spaces when invoking a constructor, but I am ok
with it.
>
> Like Gunnar (iirc) said earlier, I find having the usages be consistent
and
> different from the declarations to be a simple but effective visual clue
as
> I look through the source.
I like them to be different as well, for the same reason.
like most IDEs use colours to highlight different constructs, and I
wouldn't want to change that to use a one single colour for consistency
reasons, I would not look for spacing consistency across different things.
As Davide pointed out, the formatting rules we recommended for Eclipse have
catch statements without space so I'd stick to that: consistency is not
persuading me at all.
Sanne
>
> That's just my feelings though..
> On Jul 3, 2013 7:52 AM, "Gunnar Morling" wrote:
>
> > 2013/7/3 Steve Ebersole
> >
> >> The "original" rule was that parens should always be separated by
> >> spaces. E.g.:
> >>
> >> if (isTrue ()) { ... }
> >>
> >> Is clearly fugly.
> >>
> >> if ( isTrue () ) { ... }
> >>
> >> To me is clearly more readable.
> >>
> >> Method/constructor declarations do not use spaces inside parens simply
> >> because the arguments list cannot contain parens. Same for exception
> >> catching btw..
> >>
> > Ah, I see. This reasoning makes sense, but IMO the rule is not really
> > apparent, I guess one just needs to know it. I don't really mind either
> > way, but at least method invocations and constructor invocations should
be
> > handled consistently (i.e. both with white space following the reasoning
> > above).
> >
> >
> >
> >> On Jul 3, 2013 7:31 AM, "Gunnar Morling" wrote:
> >>
> >>> I'm voting for having white spaces in catch as well as constructor
> >>> invocations, the reason being to ensure a consistent style with method
> >>> invocations, if, while etc. I don't see an advantage in having white
space
> >>> in some of these constructs but not in others.
> >>>
> >>>
> >>> 2013/7/3 Steve Ebersole
> >>>
> There is a mix in ORM as well. My vote is for no spaces inside the
> parens
> for catch statements. I do like the spaces for if, for, while, etc
> though.
> On Jul 3, 2013 5:29 AM, "Hardy Ferentschik"
> wrote:
>
> > +1 for 'catch ( IllegalArgumentException e )' - using white spaces
> >
> > On 3 Jan 2013, at 11:07 AM, Sanne Grinovero
> wrote:
> >
> > > Looking at the following patch:
> > >
> > >
> > > }
> > > -catch (IllegalArgumentException e) {
> > > +catch ( IllegalArgumentException e ) {
> > >
> > > would you consider it an improvement in terms of consistency with
> the
> > > Hibernate style?
> > >
> > > It has always been my interpretation that we use whitespaces
inside
> > > blocks, like:
> > >
> > >
> > > if ( condition)
> > > //rather than
> > > if (condition)
> > >
> > > but we don't for constructor invocations:
> > >
> > > new Wrapper(type, param);
> > > //rather than
> > > new Wrapper( type, param );
> > >
> > > and we also do not (usually) for catch.
> > >
> > > I know that might sound like inconsistent, but the point is
> > > readability: I've got used to it and I could swear that the
> *different
> > > treating* helps with eyeball code scanning.. but I realize that
> could
> > > be a very personal opinion.
> > >
> > > So since we're encoding this rule now in checkstyle, which one
shall
> > > it be for the catch statements?
> > >
> > > My guts vote goes to
> > >
> > > }
> > > catch (IllegalArgumentException e) {
> > > ...
> > >
> > > but I'd prefer to follow the convention from ORM, if you guys
have a
> > > clear rule :-)
> > >
> > > 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
> >
> ___
> 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] [OGM] Load entities from native query results
Gunnar, Davide and I had a discussion on how to get results out of these soon to be nicely generated native queries in Hibernate OGM http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-07-03-13.59.html http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-07-03-13.59.txt http://transcripts.jboss.org/meeting/irc.freenode.org/hibernate-dev/2013/hibernate-dev.2013-07-03-13.59.log.html A result of this discussion is the following steps: 1. use the mass indexer approach as step 0 for the MongoDB query 2. explore the proper approach https://hibernate.atlassian.net/browse/OGM-293 3. reuse data returned denormalized by the underlying native query https://hibernate.atlassian.net/browse/OGM-294 3. is useful for queries but also for reguar entity fetching down the road. Emmanuel ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
[hibernate-dev] Hibernate ORM 4.2.3.Final released!
http://in.relation.to/Bloggers/HibernateORM423FinalReleased Brett Meyer Red Hat Software Engineer, Hibernate ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] new "releases" feature in GitHub
This is what I had in mind -- just gave it a shot for ORM 4.2.3.Final: https://github.com/hibernate/hibernate-orm/releases/4.2.3.Final Full accouncement text, attached release binaries, and automatic source code archives. Brett Meyer Red Hat Software Engineer, Hibernate - Original Message - From: "Sanne Grinovero" To: "Brett Meyer" Cc: "Hibernate" Sent: Wednesday, July 3, 2013 6:14:12 AM Subject: Re: [hibernate-dev] new "releases" feature in GitHub how does it help with announcements? On 3 Jul 2013 04:23, "Brett Meyer" wrote: > https://github.com/blog/1547-release-your-software > > This looks pretty useful -- download links, release notes, etc. Use it in > place of announcements on in.relation.to? ;) > > Brett Meyer > Red Hat Software Engineer, Hibernate > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Hibernate ORM 4.2.3.Final released!
Also, I'm giving the new Releases feature in GitHub a shot: https://github.com/hibernate/hibernate-orm/releases/4.2.3.Final Brett Meyer Red Hat Software Engineer, Hibernate - Original Message - From: "Brett Meyer" To: "hibernate-dev" , hibernate-annou...@lists.jboss.org Sent: Wednesday, July 3, 2013 12:07:29 PM Subject: Hibernate ORM 4.2.3.Final released! http://in.relation.to/Bloggers/HibernateORM423FinalReleased Brett Meyer Red Hat Software Engineer, Hibernate ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] new "releases" feature in GitHub
looking good! but what is the "automatic" you mention? On 3 Jul 2013 17:38, "Brett Meyer" wrote: > This is what I had in mind -- just gave it a shot for ORM 4.2.3.Final: > > https://github.com/hibernate/hibernate-orm/releases/4.2.3.Final > > Full accouncement text, attached release binaries, and automatic source > code archives. > > Brett Meyer > Red Hat Software Engineer, Hibernate > > - Original Message - > From: "Sanne Grinovero" > To: "Brett Meyer" > Cc: "Hibernate" > Sent: Wednesday, July 3, 2013 6:14:12 AM > Subject: Re: [hibernate-dev] new "releases" feature in GitHub > > how does it help with announcements? > On 3 Jul 2013 04:23, "Brett Meyer" wrote: > > > https://github.com/blog/1547-release-your-software > > > > This looks pretty useful -- download links, release notes, etc. Use it > in > > place of announcements on in.relation.to? ;) > > > > Brett Meyer > > Red Hat Software Engineer, Hibernate > > ___ > > 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] new "releases" feature in GitHub
The "Source code (zip)" and "Source code (tar.gz)" archives/links are automatically generated by GitHub based off of the tag. Everything else is manual. Brett Meyer Red Hat Software Engineer, Hibernate +1 260.349.5732 - Original Message - From: "Sanne Grinovero" To: "Brett Meyer" Cc: "Hibernate" Sent: Wednesday, July 3, 2013 1:47:09 PM Subject: Re: [hibernate-dev] new "releases" feature in GitHub looking good! but what is the "automatic" you mention? On 3 Jul 2013 17:38, "Brett Meyer" wrote: > This is what I had in mind -- just gave it a shot for ORM 4.2.3.Final: > > https://github.com/hibernate/hibernate-orm/releases/4.2.3.Final > > Full accouncement text, attached release binaries, and automatic source > code archives. > > Brett Meyer > Red Hat Software Engineer, Hibernate > > - Original Message - > From: "Sanne Grinovero" > To: "Brett Meyer" > Cc: "Hibernate" > Sent: Wednesday, July 3, 2013 6:14:12 AM > Subject: Re: [hibernate-dev] new "releases" feature in GitHub > > how does it help with announcements? > On 3 Jul 2013 04:23, "Brett Meyer" wrote: > > > https://github.com/blog/1547-release-your-software > > > > This looks pretty useful -- download links, release notes, etc. Use it > in > > place of announcements on in.relation.to? ;) > > > > Brett Meyer > > Red Hat Software Engineer, Hibernate > > ___ > > 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] new "releases" feature in GitHub
I'm actually not super impressed, the automation misses doc and we need some kind of RSS feed. Also after they stopped binary support, I don't trust them a lot in this area... But I'm a grumpy old guy so that might explain. Emmanuel On Wed 2013-07-03 18:47, Sanne Grinovero wrote: > looking good! but what is the "automatic" you mention? > On 3 Jul 2013 17:38, "Brett Meyer" wrote: > > > This is what I had in mind -- just gave it a shot for ORM 4.2.3.Final: > > > > https://github.com/hibernate/hibernate-orm/releases/4.2.3.Final > > > > Full accouncement text, attached release binaries, and automatic source > > code archives. > > > > Brett Meyer > > Red Hat Software Engineer, Hibernate > > > > - Original Message - > > From: "Sanne Grinovero" > > To: "Brett Meyer" > > Cc: "Hibernate" > > Sent: Wednesday, July 3, 2013 6:14:12 AM > > Subject: Re: [hibernate-dev] new "releases" feature in GitHub > > > > how does it help with announcements? > > On 3 Jul 2013 04:23, "Brett Meyer" wrote: > > > > > https://github.com/blog/1547-release-your-software > > > > > > This looks pretty useful -- download links, release notes, etc. Use it > > in > > > place of announcements on in.relation.to? ;) > > > > > > Brett Meyer > > > Red Hat Software Engineer, Hibernate > > > ___ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] new "releases" feature in GitHub
I was (half) joking about replacing in.relation.to and/or SF. But this seems like a good thing to supplement with. Brett Meyer Red Hat Software Engineer, Hibernate +1 260.349.5732 - Original Message - From: "Emmanuel Bernard" To: "Sanne Grinovero" Cc: "Brett Meyer" , "Hibernate" Sent: Wednesday, July 3, 2013 2:03:08 PM Subject: Re: [hibernate-dev] new "releases" feature in GitHub I'm actually not super impressed, the automation misses doc and we need some kind of RSS feed. Also after they stopped binary support, I don't trust them a lot in this area... But I'm a grumpy old guy so that might explain. Emmanuel On Wed 2013-07-03 18:47, Sanne Grinovero wrote: > looking good! but what is the "automatic" you mention? > On 3 Jul 2013 17:38, "Brett Meyer" wrote: > > > This is what I had in mind -- just gave it a shot for ORM 4.2.3.Final: > > > > https://github.com/hibernate/hibernate-orm/releases/4.2.3.Final > > > > Full accouncement text, attached release binaries, and automatic source > > code archives. > > > > Brett Meyer > > Red Hat Software Engineer, Hibernate > > > > - Original Message - > > From: "Sanne Grinovero" > > To: "Brett Meyer" > > Cc: "Hibernate" > > Sent: Wednesday, July 3, 2013 6:14:12 AM > > Subject: Re: [hibernate-dev] new "releases" feature in GitHub > > > > how does it help with announcements? > > On 3 Jul 2013 04:23, "Brett Meyer" wrote: > > > > > https://github.com/blog/1547-release-your-software > > > > > > This looks pretty useful -- download links, release notes, etc. Use it > > in > > > place of announcements on in.relation.to? ;) > > > > > > Brett Meyer > > > Red Hat Software Engineer, Hibernate > > > ___ > > > hibernate-dev mailing list > > > hibernate-dev@lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [HSEARCH] Geo queries in ElasticSearch
On Wed 2013-07-03 14:57, Nicolas Helleringer wrote: > I did not get your point Ales : > > Hibernate Search does support geo queries since 4.2 (early 2013) so > yes you can know which points are in a certain distance event with big > number of data. > > The challenge for geo facets is to do this many times (as many times > as they are defined ranges) as automatically as possible. > > Niko > > 2013/7/3 Ales Justin : > > Can you then also easily (aka really fast) know which are those points -- > > even with really big number of data? > > > > On Jul 3, 2013, at 2:14 PM, Emmanuel Bernard wrote: > > > >> I'm more interested in something like > >> > >> Within 10 kms (23) > >> Between 10 and 50 kms (45) > >> Above 50 kms (75) > >> > >> > >> On Wed 2013-07-03 11:24, Nicolas Helleringer wrote: > >>> Was is demonstrated here has nothing of a facet : these are only > >>> aggregates. > >>> > >>> > >>> GeoDistanceFacet results: > >>> - > >>> Distance from origin: 0.0 > >>> Distance to requested: 1000.0 > >>> Number of results: 29 > >>> Minimum distance: 0.0 > >>> Maximum distance: 899.5358131385483 > >>> Sum of distances: 17320.209230844222 > >>> Mean distance: 597.2485941670421 > >>> > >>> > >>> I see nothing we cannot do. > >>> > >>> Niko > >>> > >>> 2013/7/3 Emmanuel Bernard : > This morning I was reading > http://hashmade.fr/elastic-search-geo-distance-search-with-sorted-and-faceted-results-using-java-native-api/ > And the code https://github.com/jsebrien/elastic-search-tests > > I have to say that we compare quite well in number of lines of code and > readability. Considering that ElasticSearch is considered the easy tool > / API in the search space, I did not expect that. > > We could do better on the facet side, I particular to retrieve the facet > data. > > By the way, they offer a way to facet by spatial distance, Hardy, > Nicolas, how hard would it be to do the same? > > Emmanuel > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> ___ > >> hibernate-dev mailing list > >> hibernate-dev@lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > > > > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ > 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] new "releases" feature in GitHub
It's an interesting feature, but what I personally find not so good about this is that it'd add one more location where users can/need to pick up information about our projects. 2013/7/3 Brett Meyer > I was (half) joking about replacing in.relation.to and/or SF. But this > seems like a good thing to supplement with. > > Brett Meyer > Red Hat Software Engineer, Hibernate > +1 260.349.5732 > > - Original Message - > From: "Emmanuel Bernard" > To: "Sanne Grinovero" > Cc: "Brett Meyer" , "Hibernate" < > hibernate-dev@lists.jboss.org> > Sent: Wednesday, July 3, 2013 2:03:08 PM > Subject: Re: [hibernate-dev] new "releases" feature in GitHub > > I'm actually not super impressed, the automation misses doc and we need > some kind > of RSS feed. Also after they stopped binary support, I don't trust them > a lot in this area... > > But I'm a grumpy old guy so that might explain. > > Emmanuel > > On Wed 2013-07-03 18:47, Sanne Grinovero wrote: > > looking good! but what is the "automatic" you mention? > > On 3 Jul 2013 17:38, "Brett Meyer" wrote: > > > > > This is what I had in mind -- just gave it a shot for ORM 4.2.3.Final: > > > > > > https://github.com/hibernate/hibernate-orm/releases/4.2.3.Final > > > > > > Full accouncement text, attached release binaries, and automatic source > > > code archives. > > > > > > Brett Meyer > > > Red Hat Software Engineer, Hibernate > > > > > > - Original Message - > > > From: "Sanne Grinovero" > > > To: "Brett Meyer" > > > Cc: "Hibernate" > > > Sent: Wednesday, July 3, 2013 6:14:12 AM > > > Subject: Re: [hibernate-dev] new "releases" feature in GitHub > > > > > > how does it help with announcements? > > > On 3 Jul 2013 04:23, "Brett Meyer" wrote: > > > > > > > https://github.com/blog/1547-release-your-software > > > > > > > > This looks pretty useful -- download links, release notes, etc. Use > it > > > in > > > > place of announcements on in.relation.to? ;) > > > > > > > > Brett Meyer > > > > Red Hat Software Engineer, Hibernate > > > > ___ > > > > 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 mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
