metamodel tests
by Steve Ebersole
There are a bunch of test failures in the new metamodel tests. I know
this stuff is changing all the time, but we really need to work on
making sure that work we are doing is not causing regressions.
Otherwise, this work will quickly become a situation of "1 step forward,
2 steps back" instead of the other way around.
AFAICT, the errors all seem related to:
1) AttributeOverrides/orm.xml-overrides not being applied
2) funky column/table name resolution
3) general code changes based on things we discussed, without updating tests
--
steve(a)hibernate.org
http://hibernate.org
12 years, 2 months
Experiments with hibernate-ogm on Riak, Redis and Voldemort
by skawashima＠uchicago.edu
I apologize that I've just sent an empty email by accident.
I've been experimenting hibernate-ogm for several weeks using three NoSQL key-value databases such as Riak,Redis and Voldemort and got something that might be helpful to start extending hibernate-ogm. The implementation is at https://github.com/seiyak/Sample-implementation-of-hibernate-ogm.
Based on the supplied tests, the CRUD operations on them look ok. However I need to take a closer look at my implementation and hibernate-ogm itself. Next thing that I need to do is implement query part.
Once again, this is an experimenting sample implementation, so there might be something incorrect. Once it appears, I'll fix it shortly.
Thank you
Seiya
12 years, 2 months
[HSEARCH] HSEARCH-923 Use of Coordinates interface for lat ad long
by Emmanuel Bernard
Nicolas,
I'm geting a bit cold feet on our initial implementation. We have decided to use Coordinates as the placeholder of lat and long. Coordinates is an Hibernate Search interface. Reading the draft of your doc and as an app developer, I don't find it too attractive to have to use this interface in my domain model.
I'm wondering if we should rather do as Karel suggested: support the "free form" and wait for Hibernate Spatial types to introduce such a concept.
That means we need to find a way to tag the lat / long getters
## Option 1
```
@Spatial(
field="coordinates",
latitude="latitude", //property name
longitude="longitude",
method=QUAD
)
public class Restaurant {
public double getLatitude() { ... }
public double getLongitude() { ... }
}
```
### Embedded objects
```
@Spatial(
field="coordinates",
latitude="place.latitude", //property name
longitude="place.longitude",
method=QUAD
)
public class Restaurant {
public Place getPlace {} { ... }
}
//user defined
public class Place {
public double getLatitude() { ... }
public double getLongitude() { ... }
}
```
```
public class Restaurant {
@Spatial(
field="coordinates",
latitude="latitude", //property name
longitude="longitude",
method=QUAD
)
public Place getPlace {} { ... }
}
//user defined
public class Place {
public double getLatitude() { ... }
public double getLongitude() { ... }
}
```
## Option 2
```
@Spatial(
field="coordinates",
method=QUAD
)
public class Restaurant {
@Latitude(for="coordinates")
public double getLatitude() { ... }
@Longitude(for="coordinates")
public double getLongitude() { ... }
}
```
### Embedded objects
```
@Spatial(
field="coordinates",
method=QUAD
)
public class Restaurant {
public Place getPlace {} { ... }
}
//user defined
public class Place {
@Latitude(for="coordinates")
public double getLatitude() { ... }
@Longitude(for="coordinates")
public double getLongitude() { ... }
}
```
## Opinion
I am not thrilled by what I am proposing, esp since they involve String as the link in our metadata. If someone has something better, go ahead.
Otherwise, I think I like option 1 better for a few reasons:
- easier to implement
- easier to read
- supports nicely embedded objects
- does not force the embedded object to be annotated (limit of reuse?)\\
what do you all think?
12 years, 2 months
[HSearch] Beta2 for Monday
by Emmanuel Bernard
It seems most if not all opened issues for Beta2 are MassIndexing related. Sanne, will you have time to address them? Do you need specific help besides swift pull request reviews?
Emmanuel
12 years, 2 months
[Search] ParameterizedBridge API
by Sanne Grinovero
The current API reads:
public interface ParameterizedBridge {
//TODO inject Properties? since the annotations cannot support Object
attribute?
void setParameterValues(Map parameters);
}
Shall we apply the TODO, or at least change it to specify the expected
Map types?
public interface ParameterizedBridge {
void setParameterValues(Map<String,String> parameters);
}
Using generics we would keep backwards compatibility.
I'm looking at this because we make type mistakes ourselves; for
example the example
PaddedIntegerBridge is broken:
public void setParameterValues(Map parameters) {
Object padding = parameters.get( PADDING_PROPERTY );
if (padding != null) this.padding = (Integer) padding; <<<<<<< Cast exception!
}
Cheers,
Sanne
12 years, 2 months
HHH-7018 and one more change to how we serialize EntityManagerFactory instances...
by Scott Marlow
Feedback is welcome on a proposed change for HHH-7018
https://github.com/scottmarlow/hibernate-orm/commit/007e7f17eed10c6c1db55...
When we serialize the EntityManagerFactory in 4.0.0, there can be
nonserializeable objects in the EMF configuration properties (e.g.
JTA_PLATFORM, datasource, other stuff). In most cases, we will have a
session factory name (preferred) or persistence unit name to uniquely
identify the EntityManagerFactory. In 4.0.1, during serialization, we
only serialize the (hopefully) unique name.
If a duplicate EntityManagerFactory is created (by name), no immediate
error is given, instead we only give an error later when deserializing
the EMF. The HibernateException thrown during deserialization will look
like:
"registry contains more than one (" +
entityManagerFactorySet.size()+ ") entity manager factories: "
+ name
If that causes issues for any application, the SESSION_FACTORY_NAME can
be passed in from the troubled application (possibly with
SESSION_FACTORY_NAME_IS_JNDI set to false but true is also fine).
For the 4.1 release, I would like to take this one step further. The
above changes, only were made for EntityManager serialization of the EM
to EMF reference. The next step is to apply the same change to the EMF
readObject/writeObject, such that we also allow the EMF to be serialized
when it contains nonserializable objects. This also simplifies the EM
serialization, as it can just use default serialization for the EMF.
The proposed commit (to be fixed in 4.1) is at
https://github.com/scottmarlow/hibernate-orm/commit/007e7f17eed10c6c1db55....
Feedback on the change is welcome (we are building 4.1 final middle of
this week).
Scott
12 years, 2 months
