HSEARCH Preparations for 4.0.0 Final
by Emmanuel Bernard
## Timeline and work to do
Hibernate Core goes final next week if things go as planned. So it's time for us to gear towards a CR2 and release it right after Core goes final. I have done some JIRA cleanup and everything I think is important is tagged as fix version 4.0.0.CR2. Please have a look, pick up issues and fix them.
Also have a look at issues marked as 4.0.0.Final which I don't think any is critical or realistic to put in this release. See my rant about managing JIRA below on the subject. Once you have looked at them I will nuke their fix version field into oblivion.
4.0 will target Infinispan 5.0. A week or two from CR, we will go final.
4.1 will be a short cycle targeted for mid december (the final version). The idea is to align with Infinispan 5.1 and add whatever useful feature or fix we think is important.
## Managing JIRA
JIRA is not exactly a list to Santa Claus. Let me rephrase, JIRA is not a list to Santa Claus. You can't put a version number to a JIRA issue and hope things will magically be fixed in this version. The rule of thumb is simple:
1. If you think you will do it, set the version number
2. If you know someone that will likely do it, put a version number
3. if it's vitally important that this be fixed in the next version, see rule #1
Otherwise don't put a version number without asking the project lead
The rule is a bit different for the project lead as he has to draw the big picture of what a release will contain and assigning a number is the easiest solution. A corollary is that moving a problem from version n to version n+1 is useless.
Today we ended up with 60 issues that ought to be resolved in less than a week. That obviously is beyond our capacity.
Of course these rules are not hard enforced but we definitively need to shift back into a more conservative version assignment management.
By the way, I don't know if you have followed AS 7's team rant on JIRA and actionable items. While I'm not 100% inlined with their rule, I am sympathetic to the idea of a managed flow of JIRA issues. I'm not sure how this can be applied to (or at least get closer with) search, validator and ogm but I'm open to ideas.
13 years
[HSEARCH] Geospatial indexing and queries
by Emmanuel Bernard
Nicolas and I have made good progress on Geospatial queries for Hibernate Search.
# Geospatial indexing and queries
Our goal is to give a reasonable but pragmatic answer to geoloc queries. We do not try and implement the most obscure geo-projection favored by ancient greeks, we do not try and find matching elements within a triangular-shaped donut on Mars' surface etc. We have purposely limited the current implementation to:
- find matching elements in a circle (we have plans to extends to matching elements in a rectangle if popular demands arise but in our opinion this will not be useful or rather be misleading)
- use the internationally accepted geo projection as it is i18n neutral and not centered on one particular country. We can plan on opening to other projections if the need arise (esp if data points are provided in different projections).
We made sure to expose as few gory details as possible.
That being said, here are more information and questions.
The JIRA is https://hibernate.onjira.com/browse/HSEARCH-923
The branch is https://github.com/emmanuelbernard/hibernate-search/tree/HSEARCH-923
## How is geoloc data exposed to the domain model?
We plan on supporting three approaches:
### Special interface and embeddable object
Using a specific interface as the property return type: `o.h.s.spatial.Coordinates`
@Indexed
public class Address {
@Field String city;
@Spatial Coordinates location = new Coordinates() {
public double getLatitude() { ... }
public double getLongitude() { ... }
}
}
### Special interface implemented by the entity
Using a specific interface implemented by the entity: `o.h.s.spatial.Coordinates`
@Indexed @Spatial
public class Address {
@Field String city;
public double getLatitude() { ... }
public double getLongitude() { ... }
}
### Use JTS's Point type
Use `Point` as the spatial property type.
### (maybe) `double` hosted by two unrelated properties
The problem is to find a nice way to bind these properties to the spatial data.
## How is geoloc data indexed
There will be two strategies
- index latitude and longitude as is and do a AND query matching both. This typically works nicely for small datasets.
- index latitude and longitude as matching a 15 level grid (from most generic to most specific). this typically works nicely for big datasets
## Query DSL
We have worked to make a fluent spatial API to the current query DSL. Before we go on implementing it, we would like your feedback. Some points remains open.
### General overview
builder.spatial()
.scoreByProximity() //not implemented yet
.onField("coord")
.boostedTo(2)
.within(2).km()
.of( coordinates )
.createQuery();
### onField
onField is not a good name. It has a slightly meaning than when it's used in range().onField(). We need to find a better name:
- onField
- onGrid
- onCoordinates
- onLocation
This really represents the metadata set where the location will be stored. In the boolean approach, we store latitude and longitude. In the grid approach, we store latitude,
longitude and the set of grids coordinates belong to.
.onField() does accept a field name which can be the `Coordinates` property or the virtual field used by the class-level bridge (if lat and long are top level properties).
When latitude and longitude are independent properties, we would use
builder.
.onLatitudeField("lat")
.andLongitudeField("lat")
### Surface checked
#### Option 1: centeredOn
.centeredOn(double, double)
//or
.centeredOn()
.latitude(double)
.longitude(double)
//or
.centeredOn(SpatialIndexable)
.centeredOn(JTS.Point) // hard dependency on JTS even for non spatial users :(
.centeredOn(Object) //? to avoid JTS dep
- Should we have a version accepting Object?
- What is best, centeredOn(double, double) or centeredOn().latitude(double).longitude(double)?
#### Option 2: in / within
//query within circle
b.spatial()
.onField("coord")
.within(2).km()
.of(SpatialIndexable)
.within(2).km()
.of()
.latitude()
.longitude()
.createQuery()
//or with a different unit handling
//query within circle
b.spatial()
.onField("coord")
.within(2, Unit.km)
.of(SpatialIndexable)
.within(2, Unit.km)
.of()
.latitude()
.longitude()
.createQuery()
My reason to support units is that a. it's explicit and b. when those geosuckers improve, we could support time units like mins or hours. Note, that's a very hard problem to crack and solutions are resource intensive and not very accurate. None really do it correctly, not Google for sure.
We could support rectangles / boxes if really needed
//query in box
b.spatial()
.onField("coord")
.inBox()
.from()
.to()
.createQuery();
//more formal but more correct wrt projection
b.spatial()
.onField("coord")
.inBox()
.withUpperLeft()
.withLowerRight()
.createQuery();
Please give us your feedback.
## TODOs
- Implement fluent DSL
- Implement Special interface implemented by the entity
- Implement Use JTS's Point type
- Implement bridge that supports indexing for boolean queries based on lat and long instead of the grid.
- Implement @Spatial as a marker annotation for the spatial bridge
- Implement variable score based on proximity
Today we use constant score, ie in = 1, out = 0. We can think about a score that goes from 1 to 0 based on the distance from the center to the circle size
We can imagine queries that should return close elements above far elements.
Note we might need a score going from 1 to .5 or some other value. Need to think about that.
- Write how to focused doc
- Write doc on perf comparing grid vs boolean queries
- Convert to JBoss logging
- Add unit test using faceting + spatial queries
Emmanuel
13 years
JIRA issue status - Closed v. Resolved
by Steve Ebersole
We seem to have a few different understandings of Closed versus Resolved
as a status. We should come to a consensus.
According to Atlassian...
* Resolved : A resolution has been taken, and it is awaiting
verification by reporter. From here issues are either reopened, or are
closed.
* Closed : The issue is considered finished, the resolution is correct.
Issues which are not closed can be reopened.
For the most part I agree with these definitions.
The first thing to notice is that these definitions say (imply) that a
Closed issue cannot be reopened. Today, we do allow that. Do we really
want to not allow closed issues to be reopened? Partially this relies
on a few other decisions...
Should all issues that are part of a release be Closed? After an issue
has been part of a release, the normal process to do additional work on
the issue is to open a new issue. Mainly that is to keep release notes
straight. Unfortunately, as far as I can tell this would have to just
be a manual release step to transition all Resolved issues to Closed.
But I think from a release tracking perspective this is the most correct
option.
Comments. Today we allow comments on Closed issues. Unfortunately we
have to reopen the issue to then delete comments. So if we no longer
physically allow Closed issues to be reopened, then IMO we should
certainly not allow comments on Closed issues.
Which brings us to... do we really want to not allow Closed issues to be
reopened? I mean actually remove the transition? Or do we just want to
say that as a standard procedure we do not reopen Closed issues?
--
steve(a)hibernate.org
http://hibernate.org
13 years
Re: [hibernate-dev] Question in relation to Hibernate4.0 Final
by Strong Liu
Max?
-------------------------
Best Regards,
Strong Liu <stliu at hibernate.org>
http://about.me/stliu/bio
On Dec 19, 2011, at 8:59 PM, Guenther Demetz wrote:
> Hi Strong Liu,
>
> do you know, when it is planned a Hibernate-Tools release compatible to Hibernate-Core 4.0 Final ?
>
> Me and probably many other hibernate users cannot switch to Hibernate-Core 4.0
> as long there no compatible hibernate-tools version available.
>
> best regards
> Guenther Demetz
>
> On 09/07/2011 02:10 PM, Strong Liu wrote:
>>
>> that just because of we don't have enough resource working on hibernate-tools :(
>> meanwhile, you can use hibernate-tools with hibernate-core 3.6 to generate schemas
>>
>> and thanks for the patches i'm working on it
>>
>> -----------
>> Strong Liu <stliu(a)hibernate.org>
>> http://hibernate.org
>> http://github.com/stliu
>>
>> On Sep 7, 2011, at 8:09 PM, Guenther Demetz wrote:
>>
>>> Hi Strong Liu,
>>>
>>> as requested I attached a testcase to HHH-6635.
>>>
>>> I have another question regarding Hibernate4:
>>>
>>> Till now I used hbm2ddl ant-target of hibernate-tools to create new database schemas.
>>> but I noticed that so far all Hibernate4 prereleases were provided without a compatible version of hibernate-tools.
>>>
>>> -hibernate-tools3.2.4.GA still makes reference to org.hibernate.util.StringHelper
>>> which in hibernate4 has been moved to package org.hibernate.internal.util
>>>
>>> -method org.hibernate.tool.hbm2ddl.ManagedProviderConnectionHelper#prepare() in Hiberante-core 4.0.0CR2 has an unimplemented body, so no connection is provided for the hbm2ddl tool
>>>
>>> So my question is:will hibernate-tools still be supported with hibernate4 or has this module become deprecated ?
>>>
>>> best regards
>>> Guenther Demetz
>>>
>>> --
>>> Würth Phoenix S.r.l.
>>> Günther Demetz
>>> Product Development (CIS)
>>> Via Kravogl 4
>>> I-39100 Bolzano
>>> Direct: +39 0471 564 061
>>> Fax: +39 0471 564 122
>>> E-Mail: guenther.demetz(a)wuerth-phoenix.com
>>> Website: www.wuerth-phoenix.com
>>>
>>>
>>>
>>>
>>
>
>
> --
> Würth Phoenix S.r.l.
> Günther Demetz
> Product Development (CIS)
> Via Kravogl 4
> I-39100 Bolzano
> Direct: +39 0471 564 061
> Fax: +39 0471 564 122
> E-Mail: guenther.demetz(a)wuerth-phoenix.com
> Website: www.wuerth-phoenix.com
13 years
JIRA Pull Request Workflow
by Steve Ebersole
During today's IRC meeting we discussed some changes to JIRA to better
deal with GitHub pull requests.
The first change was to introduce a new issue field for holding a list
of pull request urls.
There is also a new issue status named "Pull Request Pending".
Currently it is not "hooked in" because there are no active workflow
transtions using it.
That is the next step, to introduce a specific JIRA workflow to manage
the transitions around "Pull Request Pending".
In terms of in-flowing transitions, I see:
* Open -> Pull Request Pending
* Reopened -> Pull Request Pending
* In Progress -> Pull Request Pending
* Awaiting Test Case -> Pull Request Pending
* Resolved -> Pull Request Pending
For out-flowing:
* Pull Request Pending -> Open
* Pull Request Pending -> Reopened
* Pull Request Pending -> In Progress
* Pull Request Pending -> Resolved
* Pull Request Pending -> Closed
So far all that is manual.
The final step would be integration with GitHub based on its event
handling, specifically pull request events to add some automation. For
sure one automation would be when a pull request is added, to add the
pull request url to the JIRA issue(s). Potentially we would transition
the issue to "Pull Request Pending" status. Potentially on closing the
pull request we might also transition the issue back out of "Pull
Request Pending" status. However, there are some difficulties with
these automated transitions. See the weekly IRC developer meeting notes
from 12/20 for details.
Thoughts/ideas?
--
steve(a)hibernate.org
http://hibernate.org
13 years
Is there any official Hibernate framework in C++ ?
by f s
Hi,
I would like to use Hibernate in C++. However, it seems to me that there
are no official Hibernate or wrapper frameworks for the purpose.
Do you think that it would be workable as production ready software if
Hibernate is used through JNI from C++ ?
Or is there any official plan to port Hibernate to C++ ?
I've recently added a project called
CppHibernate<https://github.com/seiyak/CppHibernate>at github to use
Hibernate in C++ through JNI which looks like below.
CppHibernateJVMConfiguration
configuration("/root/classpath/your/hibernate.cfg.xml/lives");
URLClassLoader loader =
URLClassLoader(configuration.getJNIEnv(),"/path/to/hibernate/jar/files");
CppHibernateObjectHelper helper =
CppHibernateObjectHelper(configuration.getJNIEnv(),&loader);
CppHibernate hibernate = CppHibernate(&configuration,&loader);
CppHibernateSession *session =
hibernate.getSessionFactory()->getCurrentSession();
CppHibernateTransaction *transaction = session->beginTransaction();
//// do some work. Here saves an object.
CppHibernateJObject *obj1 =
helper.createJObjectWith("org.hibernateDomain.Event");
CppHibernateJStringObject *obj1Str =
helper.createJStringObjectWith("title1");
obj1->setVal("title",obj1Str);
session->saveObj(obj1);
delete obj1;
delete obj1Str;
transaction->commit();
delete transaction;
delete session;
If this question has already been asked or is irrelevant to this mailing
list, please discard the question.
Thank you
Seiya
13 years
