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 th
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 m
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"
Sen
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
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:
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
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
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
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
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/hi
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 de
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
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, "
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:
>
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
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 automatica
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 cat
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
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/con
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
> coun
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 par
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.
W
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 wrot
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 th
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
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:
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
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
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
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:
> ---
+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 i
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 Eng
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
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.5358131385
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 (
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 t
36 matches
Mail list logo
