You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Constantin Wolber <co...@medicalcolumbus.de> on 2014/12/04 16:20:59 UTC
REST API Alternative to admin/luke
Hi,
we use dynamic Fields in our schema.
If I use the admin/luke URL all those dynamic fields are listed with their actual name.
If I use the rest endpoint /schema/fields only the hard coded fields are returned. And dynamicFields only returns the definition of the dynamicFields. I was expecting a similar result like the one through the admin/luke URL which would return all the hard coded fields and all the ones dynamically being generated.
Does anybody know if there exists something like this or is luke the only chance I have?
Regards
Constantin
--
Constantin Wolber
Head of IT and Product Management
medical columbus AG
Herzog-Adolph-Str. 7
D-61462 Königstein
www.medicalcolumbus.de<http://www.medicalcolumbus.de/>
tel + 49 (0) 61 74 / 96 17-60
fax +49 (0) 61 74 / 96 17-10
constantin.wolber@medicalcolumbus.de
Amtsgericht Königstein, HRB 4906
Vorstand: Dirk Isenberg
Aufsichtsratsvorsitzender: Manfred Hellwig
[Beschreibung: medical columbus logo]
Re: REST API Alternative to admin/luke
Posted by Ahmet Arslan <io...@yahoo.com.INVALID>.
Hi,
I use it in production with numTerms=0 parameter set.
Ahmet
On Thursday, December 4, 2014 10:48 PM, Constantin Wolber <co...@medicalcolumbus.de> wrote:
Hi,
Basically using an endpoint in the admin section is something that makes me think if there is an alternative.
And it would have been nice to have a straight forward resource oriented approach. Which the Luke certainly is not.
Regards
Constantin
> Am 04.12.2014 um 20:46 schrieb Chris Hostetter <ho...@fucit.org>:
>
>
> : I did not oversee a feature of the rest endpoints. So probably we will
> : stick with the admin/luke endpoint to achieve our goal.
>
> Ok ... i mean ... yeah -- the /admin/luke endpoint exists to tell you what
> fields are *actually* in your index, regardless of who/how they are in
> your index.
>
> the Schema API is for letting you do CRUD operations on your *schema* -
> even if those fields (or dynamic fields patterns) aren't used in your
> index.
>
> so based on what you said your goal is, /admin/luke is exactly what you
> want.
>
> but since you already knew about /admin/luke, and already knew it gave you
> exactly what you wanted, i'm stll not sure i understand what prompted you
> to ask your question about trying tofind a diff way of doing this... ?
>
> -Hoss
> http://www.lucidworks.com/
Re: REST API Alternative to admin/luke
Posted by Constantin Wolber <co...@medicalcolumbus.de>.
Hi,
Basically using an endpoint in the admin section is something that makes me think if there is an alternative.
And it would have been nice to have a straight forward resource oriented approach. Which the Luke certainly is not.
Regards
Constantin
> Am 04.12.2014 um 20:46 schrieb Chris Hostetter <ho...@fucit.org>:
>
>
> : I did not oversee a feature of the rest endpoints. So probably we will
> : stick with the admin/luke endpoint to achieve our goal.
>
> Ok ... i mean ... yeah -- the /admin/luke endpoint exists to tell you what
> fields are *actually* in your index, regardless of who/how they are in
> your index.
>
> the Schema API is for letting you do CRUD operations on your *schema* -
> even if those fields (or dynamic fields patterns) aren't used in your
> index.
>
> so based on what you said your goal is, /admin/luke is exactly what you
> want.
>
> but since you already knew about /admin/luke, and already knew it gave you
> exactly what you wanted, i'm stll not sure i understand what prompted you
> to ask your question about trying tofind a diff way of doing this... ?
>
> -Hoss
> http://www.lucidworks.com/
Re: REST API Alternative to admin/luke
Posted by Chris Hostetter <ho...@fucit.org>.
: I did not oversee a feature of the rest endpoints. So probably we will
: stick with the admin/luke endpoint to achieve our goal.
Ok ... i mean ... yeah -- the /admin/luke endpoint exists to tell you what
fields are *actually* in your index, regardless of who/how they are in
your index.
the Schema API is for letting you do CRUD operations on your *schema* -
even if those fields (or dynamic fields patterns) aren't used in your
index.
so based on what you said your goal is, /admin/luke is exactly what you
want.
but since you already knew about /admin/luke, and already knew it gave you
exactly what you wanted, i'm stll not sure i understand what prompted you
to ask your question about trying tofind a diff way of doing this... ?
-Hoss
http://www.lucidworks.com/
Re: REST API Alternative to admin/luke
Posted by Constantin Wolber <co...@medicalcolumbus.de>.
Hi,
And thanks for the answers. So my understanding is at least correct that I did not oversee a feature of the rest endpoints. So probably we will stick with the admin/luke endpoint to achieve our goal.
Since you have been telling me a lot about the xy problem, I will of course give you some more information regarding the X.
In the application we integrate the search based on solr. We don't know exactly all fields that will be indexed they can change dynamically. So our idea was to build up a general search service that will connect to the solr core and build the available search options dynamically. If that service encounters a field that is of type tint it can offer a range search to the user. With that approach it would require no change of the application if a new field is added.
Hope that makes it a bit clearer
Regards
Constantin
> Am 04.12.2014 um 18:12 schrieb Chris Hostetter <ho...@fucit.org>:
>
>
> : Subject: REST API Alternative to admin/luke
>
> this smells like an XY problem ... if /admin/luke gives you the data you
> want, why not use /admin/luke ? ... what is it about /admin/luke that
> prevents you from solving your problem? what is your ultimate goal?
>
> : If I use the admin/luke URL all those dynamic fields are listed with their actual name.
> ...
> : dynamicFields. I was expecting a similar result like the one through the
> : admin/luke URL which would return all the hard coded fields and all the
> : ones dynamically being generated.
>
> https://people.apache.org/~hossman/#xyproblem
> XY Problem
>
> Your question appears to be an "XY Problem" ... that is: you are dealing
> with "X", you are assuming "Y" will help you, and you are asking about "Y"
> without giving more details about the "X" so that we can understand the
> full issue. Perhaps the best solution doesn't involve "Y" at all?
> See Also: http://www.perlmonks.org/index.pl?node_id=542341
>
>
>
> -Hoss
> http://www.lucidworks.com/
Re: REST API Alternative to admin/luke
Posted by Chris Hostetter <ho...@fucit.org>.
: Subject: REST API Alternative to admin/luke
this smells like an XY problem ... if /admin/luke gives you the data you
want, why not use /admin/luke ? ... what is it about /admin/luke that
prevents you from solving your problem? what is your ultimate goal?
: If I use the admin/luke URL all those dynamic fields are listed with their actual name.
...
: dynamicFields. I was expecting a similar result like the one through the
: admin/luke URL which would return all the hard coded fields and all the
: ones dynamically being generated.
https://people.apache.org/~hossman/#xyproblem
XY Problem
Your question appears to be an "XY Problem" ... that is: you are dealing
with "X", you are assuming "Y" will help you, and you are asking about "Y"
without giving more details about the "X" so that we can understand the
full issue. Perhaps the best solution doesn't involve "Y" at all?
See Also: http://www.perlmonks.org/index.pl?node_id=542341
-Hoss
http://www.lucidworks.com/
Re: REST API Alternative to admin/luke
Posted by Shawn Heisey <ap...@elyograg.org>.
On 12/4/2014 8:20 AM, Constantin Wolber wrote:
> we use dynamic Fields in our schema.
>
>
>
> If I use the admin/luke URL all those dynamic fields are listed with
> their actual name.
>
>
>
> If I use the rest endpoint /schema/fields only the hard coded fields
> are returned. And dynamicFields only returns the definition of the
> dynamicFields. I was expecting a similar result like the one through
> the admin/luke URL which would return all the hard coded fields and
> all the ones dynamically being generated.
>
>
>
> Does anybody know if there exists something like this or is luke the
> only chance I have?
>
Luke is a lucene-level tool, and at the Lucene level, there is no
schema. Lucene doesn't know what a dynamic field is ... effectively
they're ALL dynamic.
The /schema endpoints are looking at the schema definition, not the
index ... so they cannot know what actual fields are in the index.
What you're after will require a new feature. You can file an issue in
Apache Jira under the Solr project. This will require an account on Jira.
https://issues.apache.org/jira/browse/SOLR
The project is all volunteer, so filing an issue to request a new
feature does not guarantee that the feature will be built.
Thanks,
Shawn