See details at http://in.relation.to/Bloggers/HibernateORM430Beta3Release
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
We're starting a series of refactorings in Hibernate Search to improve
how we handle the entity mapping to the index; to summarize goals:
1# Expose the Metadata as API
We need to expose it because:
a - OGM needs to be able to read this metadata to produce appropriate queries
b - Advanced users
A proposal to get Facet.getValue more usable.
https://hibernate.atlassian.net/browse/HSEARCH-1343
On Wed 2013-05-29 14:33, Emmanuel Bernard wrote:
> Actually a List might make sense if the order you define faceting is the
> order you want to expose it. But that's a tiny bit far fetched.
>
> I wo
Actually a List might make sense if the order you define faceting is the
order you want to expose it. But that's a tiny bit far fetched.
I would love for our API to be easily consumed by UIs but it's a tiny
bit impractical at the moment. I've identified the name list issue,
serializability is a co
Trying to write a slightly generic code listing the facets and exposing
them in a UI. I cannot find a way to list the faceting requests applied.
Am I missing something? What do you think of adding
interface FacetingManager {
List getFacetingNames();
...
}
I'd love a less
Get rid of it. I forgot about that actually.
It is still an interesting idea to lower the barrier to people adding data
source integration with Hibernate Search but if it requires a complete rewrite,
better remove this experiment.
On 28 mai 2013, at 13:38, Sanne Grinovero wrote:
> On 19 May