Re: [hibernate-dev] HSEARCH FacetManager.getFacetingNames()
by Emmanuel Bernard
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 concern (JSON) and Facet.getValue() for range
facets is crap to expose.
Emmanuel
On Wed 2013-05-29 14:11, Hardy Ferentschik wrote:
> One could also return the FacetRequest instances. Something like:
>
> interface FacetingManager {
> Set<FacetingRequest> getAppliedFacetRequests();
> }
>
> Either way it should probably be a set.
>
> --Hardy
>
> On 29 Jan 2013, at 1:10 PM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>
> > 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<String> getFacetingNames();
> > ...
> > }
> >
> > I'd love a less stringy API but I am out of idea.
> >
> > Emmanuel
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
13 years, 1 month
HSEARCH FacetManager.getFacetingNames()
by Emmanuel Bernard
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<String> getFacetingNames();
...
}
I'd love a less stringy API but I am out of idea.
Emmanuel
13 years, 1 month
Search: Someone needing the standalone FullTextManager ?
by Sanne Grinovero
There is an experimental feature in Hibernate Search which is as well
known and as well documented as an easter egg:
org.hibernate.search.sandbox.standalone.FullTextManager
allows to use Hibernate Search in "standalone" mode, i.e. without a
database and storing all data in the Lucene index only.
This doesn't even have tests, but hasn't harmed any kitten so far.
However now while I'm looking at doing some refactorings in
preparation of Lucene 4, this looks like something that will need a
complete rewrite, and is adding some resistance already by depending
on deprecated methods which I'd rather remove asap.
So I'm proposing to delete it, for the time being with no replacement.
If there is interest we'd need to rewrite it anyway, but I'd prefer
doing that eventually after the migration.
Are we all ok with this?
Cheers,
Sanne
13 years, 1 month
OGM Roadmap
by Emmanuel Bernard
Hello everyone,
Since Hibernate OGM is back with Davide and Gunnar working actively on it, I put in the wiki a roadmap for Hibernate OGM with things we or or less formally discussed in the past.
https://community.jboss.org/wiki/HibernateOGMRoadmap
That's (always) a draft and we can discuss priorities. Have a look and let's discuss what you think.
Emmanuel
13 years, 1 month
Github not feeling to well today
by Sanne Grinovero
careful, we just noticed today that github is not showing the same
consistent list of open pull requests to all users.
Specifically on Hibernate Search there are two pulls open but Hardy
doesn't see them in his UI (and it's not a browser problem).
If Hardy tries to to reach the URL directly he gets a 404 on both Search pulls.
If Gunnar tries, he can reach one of them but gets a 404 on the other.
Both URLs work for me.
Hardy merged the second pull from command line as usual, and I could
confirm the state of the pull progressed correctly, and received the
usual notifications. So nothing seems to be lost, just don't trust the
web ui too much.
Sanne
13 years, 2 months
