Re: [ANNOUNCE] Apache Solr TLP - Mailing lists created

[Malcolm Upayavira Holmes]

Anyone who struggles to get themselves unsubscribed is welcome to contact me. I 
have the ability to remove people - I just need to receive an email from the 
address that is subscribed.

Malcolm / Upayavira

On Sat, 6 Mar 2021, at 12:54 AM, Anshum Gupta wrote:
> As a lot of you reached out to me about wanting to unsubscribe and I'm unable 
> to manually process this for each of you, 
> 
> I recommend folks who want to unsubscribe from a mailing list to do so by 
> just sending an email to -unsubscr...@lucene.apache.org or 
> -unsubscr...@solr.apache.org, based on what the address for the 
> mailing list is e.g. If you want to unsubscribe from general@l.a.o, you can 
> do so by sending an email to general-unsubscribe@l.a.o.
> 
> 
> 
> On Fri, Mar 5, 2021 at 3:33 PM Anshum Gupta  wrote:
>> 
>> Hi everyone,

>> 

>> I'd like to inform you that new mailing lists have been created as part of 
>> the bootstrapping of the newly created Apache Solr TLP. Below are all the 
>> lists and their corresponding subscription request addresses that will be 
>> used for Solr going forward:

>> 

>> 1. *Solr Dev* - d...@solr.apache.org [dev-subscr...@solr.apache.org]

>> 2. *Builds* - bui...@solr.apache.org [builds-subscr...@solr.apache.org]

>> 3. *Commits* - comm...@solr.apache.org [commits-subscr...@solr.apache.org]

>> 4. *Issues* - iss...@solr.apache.org [issues-subscr...@solr.apache.org]

>> 

>> The *Solr user mailing list has been migrated* from 
>> solr-u...@lucene.apache.org to *us...@solr.apache.org*. As part of this 
>> migration, all people who were subscribed to the old list continue to be 
>> subscribed to the new one. Any email sent to the old list going forward will 
>> automatically be redirected to the new address with an updated reply-to 
>> address i.e. emails for existing threads will be gracefully migrated. Please 
>> fix any mail filters you may have for this list.

>> 

>> For more information please see - 
>> https://solr.apache.org/community.html#mailing-lists-chat

>> 

>> Feel free to reach out to the Solr PMC in case of any questions or issues.

>> 

>> -Anshum

>> On behalf of the Apache Solr PMC

>> 
> 
> 
> -- 
> Anshum Gupta

Re: Renaming SolrCloud

[Malcolm Upayavira Holmes]

Solr can run Zookeeper embedded. Just make the 'standalone' version run a 
Zookeeper, then you can deprecate the standalone mode entirely.

Also, given that installing ZooKeeper is a pain, and that Solr has the embedded 
ability to run ZooKeeper, it always seemed a good idea to me to have the option 
to run ZK from within the Solr codebase, e.g:

 solr zookeeper start --various=options

Would start a Zookeeper instance, and make one less thing to go download.

Upayavira

On Mon, 14 Oct 2019, at 5:40 PM, Doug Turnbull wrote:
> I agree very much on normalizing to one mode of running Solr
> 
> So long as the 'cluster mode' hello world is easier than having to think a 
> lot about zookeeper and other hard things. One reason people use standalone 
> mode because it's as simple as "Point '/bin/solr' at config directory and 
> go". If there's just cluster mode, it all should be dead simple to help 
> newbies play around with Solr without thinking that hard
> 
> -Douc
> 
> On Mon, Oct 14, 2019 at 12:36 PM Houston Putman  
> wrote:
>> Jan,
>> 
>> I agree strongly with your last point. And in case you haven't seen it 
>> before, there is a solr k8s operator, with a growing community, under 
>> development at https://github.com/bloomberg/solr-operator.
>> 
>> I agree that taking control of the solr docker images could be a good idea. 
>> That way, it could have larger involvement from the community and grow more 
>> organically with changes in Solr itself.
>> 
>> - Houston
>> 
>> On Tue, Oct 8, 2019 at 8:25 PM Noble Paul  wrote:
>>> Why even "cluster mode" or "cloud mode"?
>>> 
>>>  Solr, by default , should use the cluster mode. So in all our
>>>  documentation, we should use just "Solr" and it should refer to a
>>>  "cluster mode of Solr"
>>> 
>>>  Wherever we don't have a "cluster mode" should be explicitly qualified
>>>  as "standalone Solr"
>>> 
>>>  On Wed, Oct 2, 2019 at 1:24 PM David Smiley  
>>> wrote:
>>>  >
>>>  > I hear you and sympathize but "SolrCloud" has been used long enough that 
>>> I doubt the trouble is worth it. I guess that makes me "+0". That said, I 
>>> think it wouldn't hurt to formalize "standalone mode" as-such and perhaps 
>>> say more explicitly that SolrCloud == "cluster mode" even if we don't 
>>> eliminate SolrCloud terminology.
>>>  >
>>>  > And as SolrCloud ... errr... "cluster mode" I mean, gains in usage 
>>> relative to "standalone mode", perhaps we can reference SolrCloud less 
>>> often and sorta assume that and instead make exceptions in documentation to 
>>> standalone mode specifics where we call that out as such. It's a loose 
>>> idea; I'm don't have an example in mind.
>>>  >
>>>  > Similar to the above notion, maybe "CloudSolrClient" could be more 
>>> invisible without renaming it. Imagine SolrClient.createFromZooKeeper() 
>>> etc. static methods that instantiate CloudSolrClient by default. Just a 
>>> thought.
>>>  >
>>>  > ~ David Smiley
>>>  > Apache Lucene/Solr Search Developer
>>>  > http://www.linkedin.com/in/davidwsmiley
>>>  >
>>>  >
>>>  > On Mon, Sep 30, 2019 at 11:19 AM Shawn Heisey  
>>> wrote:
>>>  >>
>>>  >> On 9/30/2019 6:59 AM, Ishan Chattopadhyaya wrote:
>>>  >> > I propose that we rename SolrCloud mode to "cluster mode" such that
>>>  >> > there shall be "Apache Solr", running in either "standalone mode" or
>>>  >> > "cluster mode". We can effect this renaming 9.0 onwards, if we have
>>>  >> > consensus.
>>>  >> >
>>>  >> > I am open to any other proposal as well, so long as we drop the 
>>> "cloud"
>>>  >> > in the name.
>>>  >>
>>>  >> I see your point, but I think that "cloud" is so entrenched in the
>>>  >> overall consciousness of the software that changing it will not be easy.
>>>  >>
>>>  >> Maybe it might be something we could accomplish slowly, over the rest of
>>>  >> 8.0's lifetime and the entire 9.0 lifetime. Begin changing the
>>>  >> terminology we use in communication, start shifting documentation and
>>>  >> code, with a hard cutover in a later major version, perhaps 10.0 or 
>

[jira] [Commented] (SOLR-13162) Admin UI development-test cycle is slow

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-13162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16749166#comment-16749166
 ] 

Upayavira commented on SOLR-13162:
--

This sounds like a very simple idea that would have saved me a lot of time back 
in the day (when I was working on the UI a lot).

> Admin UI development-test cycle is slow
> ---
>
> Key: SOLR-13162
> URL: https://issues.apache.org/jira/browse/SOLR-13162
> Project: Solr
>  Issue Type: New Feature
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jeremy Branham
>Priority: Minor
>
> When developing the admin user interface, it takes a long time to rebuild the 
> server to do testing.
> It would be nice to have a small test harness or the admin ui, so that 'ant 
> server' doesnt need to be executed before testing changes.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Poll: Merge jira/http2 to master branch

[Malcolm Upayavira Holmes]

Uwe - there is already a release newer than the commit

On Tue, 27 Nov 2018, at 8:03 AM, Uwe Schindler wrote:
> Ah I figured out, there is an issue open already:
> https://github.com/google/conscrypt/issues/560
> 
> Seems to be closed, so we have to wait for a new release, right? 
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
> > -Original Message-
> > From: Uwe Schindler 
> > Sent: Tuesday, November 27, 2018 8:48 AM
> > To: dev@lucene.apache.org
> > Subject: RE: Poll: Merge jira/http2 to master branch
> > 
> > It seems to work with Java 9/10/11, but with Java 8 almost all Solr tests 
> > fail.
> > Reason is a mising JAR library: conscrypt.jar (which seems to be used by 
> > Jetty
> > to support some HTTP/2 requires stuff not included in the JDK).
> > 
> > We should at least disable HTTP/2 in Java 8 or add this library (seems to
> > contain native code): https://github.com/google/conscrypt#uber-jar
> > 
> > Uwe
> > 
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: u...@thetaphi.de
> > 
> > > -Original Message-
> > > From: Uwe Schindler 
> > > Sent: Tuesday, November 27, 2018 12:38 AM
> > > To: dev@lucene.apache.org
> > > Subject: RE: Poll: Merge jira/http2 to master branch
> > >
> > > OK,
> > >
> > > I created 4 Jobs on Policeman Jenkins (Linux, Windows, macos, Solaris). On
> > > ASF Jenkins I created the standard "tests" job for now, others can be 
> > > added
> > > later. They are called "http2" at the place of the version (instead of 
> > > "7.x",
> > > "7.6", "master").
> > >
> > > Let's see how it behaves,
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > Achterdiek 19, D-28357 Bremen
> > > http://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Uwe Schindler 
> > > > Sent: Tuesday, November 27, 2018 12:22 AM
> > > > To: dev@lucene.apache.org
> > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > >
> > > > Ah sorry, I did not see the ping. Where did you try to contact me?
> > > >
> > > > Uwe
> > > >
> > > > -
> > > > Uwe Schindler
> > > > Achterdiek 19, D-28357 Bremen
> > > > http://www.thetaphi.de
> > > > eMail: u...@thetaphi.de
> > > >
> > > > > -Original Message-
> > > > > From: Chris Hostetter 
> > > > > Sent: Monday, November 26, 2018 10:59 PM
> > > > > To: dev@lucene.apache.org
> > > > > Subject: RE: Poll: Merge jira/http2 to master branch
> > > > >
> > > > >
> > > > > : The job would use the usual randomization anyways, so what's your
> > > > > : special request? So we should see an improvement asap.
> > > > >
> > > > > No special request beyond asking you to setup a job on your personal
> > > > > jenkins server -- just pointing out that i tried asking you for this 
> > > > > via
> > > > > jira ping 2 weeks ago :)
> > > > >
> > > > > And yes: if my experimentation is correct, we should see a much lower
> > > rate
> > > > > of failures from your box when testing Dat's http2 branch with java>9 
> > > > > vs
> > > > > what we see w/master & 7x
> > > > >
> > > > > : > : I’d prefer to just add jenkins jobs for the “http2” branch and 
> > > > > not yet
> > > > > : >
> > > > > : > Uwe: note that in particular it would be really helpful to have a
> > > > > : > jira/http2 jenkins job setup on your policeman's jenkins box, 
> > > > > where
> > > > java11
> > > > > : > and java12 are randomized, since you seem to hit the java>9 SSL
> > > related
> > > > > : > bugs the most, and AFAICT those problems are fixed on the
> > jira/http2
> > > > > : > branch -- see comments in SOLR-12990 (and related SOLR-12988)
> > > > >
> > > > >
> > > > > -Hoss
> > > > > http://www.lucidworks.com/
> > > >
> > > >
> > > > -
> > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > >
> > >
> > > -
> > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > > For additional commands, e-mail: dev-h...@lucene.apache.org
> > 
> > 
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8207) Add "Nodes" view to the Admin UI "Cloud" tab

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16575965#comment-16575965
 ] 

Upayavira commented on SOLR-8207:
-

If a shard is not active, then make it grey as well as labelling it?

> Add "Nodes" view to the Admin UI "Cloud" tab
> 
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI
>Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-8207.patch, SOLR-8207_shardstate.patch, 
> SOLR-8207_shardstate.patch, SOLR-8207_underscores.patch, 
> SOLR-8207_underscores.patch, image-2018-08-10-10-33-08-290.png, 
> node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png, nodes.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Comment Edited] (SOLR-11905) Input box for json.facet in Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574867#comment-16574867
 ] 

Upayavira edited comment on SOLR-11905 at 8/9/18 1:56 PM:
--

A simple text area, with a link to some decent documentation?


was (Author: upayavira):
A simple text box, with a link to some decent documentation?

> Input box for json.facet in Admin UI
> 
>
> Key: SOLR-11905
> URL: https://issues.apache.org/jira/browse/SOLR-11905
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: newdev
>
> We need an input box for JSON facet. I imagine to add another text-box that 
> appears when you click the "facet" checkbox in the Query tab of the Admin UI. 
> Alternatively it could be a separate checkbox for "JSON facet".
>  
> The text box should be several lines high to facilitate easy copy/paste of 
> JSON.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-11905) Input box for json.facet in Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16574867#comment-16574867
 ] 

Upayavira commented on SOLR-11905:
--

A simple text box, with a link to some decent documentation?

> Input box for json.facet in Admin UI
> 
>
> Key: SOLR-11905
> URL: https://issues.apache.org/jira/browse/SOLR-11905
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: newdev
>
> We need an input box for JSON facet. I imagine to add another text-box that 
> appears when you click the "facet" checkbox in the Query tab of the Admin UI. 
> Alternatively it could be a separate checkbox for "JSON facet".
>  
> The text box should be several lines high to facilitate easy copy/paste of 
> JSON.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16569388#comment-16569388
 ] 

Upayavira commented on SOLR-7767:
-

This pic looks great. My question is whether you can draw more summary out of 
it and present it visually.

You have the "Status: green". Could that be a green bar across the top?

You only show a single ZK host. How would multiples show up? Perhaps they could 
show up as tabs? Or a list of hosts on the left, can be clicked to reveal the 
data about that node. Could you draw out things about the nodes, such as 
whether it is standalone/follower/etc as that is important, then hide 
(collapsed?) the details such as data size, etc?

Just some thoughts.

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: zk-status-error.png, zk-status-new.png, zk-status-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16568522#comment-16568522
 ] 

Upayavira commented on SOLR-7767:
-

The way zookeeper is handled in the backend of the admin UI is a mess. A simple 
API that returns data as the UI expects it would be a great improvement.

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: zk-status-error.png, zk-status-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16567898#comment-16567898
 ] 

Upayavira commented on SOLR-8207:
-

Yes, no const or let.

Or, we add a transpile stage, which gets you the lot of it, and other benefits, 
and needs to be done at some point. It may help with Angular 2 migration too.

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>    Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16567560#comment-16567560
 ] 

Upayavira commented on SOLR-8207:
-

Because we don't transpile our sources, we need to use a very basic JavaScript. 
To use later stuff, we would need to add a transpile stage to our build 
process. That wouldn't be a bad thing, we could add modification too, but it 
would be a reasonable size task.

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>    Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16566528#comment-16566528
 ] 

Upayavira commented on SOLR-8207:
-

You said above that you would keep the link as ~cloud. I would suggest that 
that is likely to create confusion in the future. How about change the active 
link to ~cluster, but make ~cloud work too, or make ~cloud a redirect to 
~cluster? That way, anyone who expects the old URL to work won't be 
disappointed, yet at the same time the UI is consistent within itself?

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>    Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Fix For: master (8.0), 7.5
>
> Attachments: SOLR-8207-refguide.patch, node-compact.png, 
> node-details.png, node-hostcolumn.png, node-toggle-row-numdocs.png, 
> nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: query other solr collection from within a solr plugin

[Upayavira]

Go look in the source for the Join query parser. It does this.

Upayavira

On Thu, 26 Jul 2018, at 1:04 PM, Nicolas Franck wrote:
> I'm writing a solr plugin in java that has to query another solr 
> collection to gather
> information. What is the best way to do this?
> 
> For now I'm just using a SolrClient ( CloudSolrClient ), but has several 
> disadvantages:
> 
> * you have to extract from core metadata where your server resides, and 
> setup your SolrClient accordingly.
> * you are just knocking at the same door
> * search has to go over http for the same core.
> 
> Is there a better way? Are there any examples?
> 
> Thanks in advance
> 
> Nicolas Franck
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16469296#comment-16469296
 ] 

Upayavira commented on SOLR-8207:
-

How about making it default for Solr 8.0? It is definitely a better panel than 
the graph one, but perhaps good to maintain consistency through minor versions?

 

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>    Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7767) Zookeeper Ensemble Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7767?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16467032#comment-16467032
 ] 

Upayavira commented on SOLR-7767:
-

This is fantastic to see!

Question - is it possible to show just the things we need to know, and then 
have an 'advanced' button to show all of those parameters? I'd say status, 
follower/leader/etc is really important, whilst the rest might be overwhelming.

 

 

> Zookeeper Ensemble Admin UI
> ---
>
> Key: SOLR-7767
> URL: https://issues.apache.org/jira/browse/SOLR-7767
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, SolrCloud
>Reporter: Aniket Khare
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: zk-status-error.png, zk-status-tab.png
>
>
> For SolrCloud mode can we have the functionality to display the live nodes 
> from the zookeeper ensemble. So that user can easily get to know if any of 
> zookeeper instance is down or having any other issue.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16465024#comment-16465024
 ] 

Upayavira commented on SOLR-8207:
-

Great comments from Shawn. A few more after playing with that link

 * If you click on a node cell, it only opens up the first instance row, not 
all for that node.
  * If the window is too narrow, something odd happens with the text in the 
right-hand column



Otherwise, loving the breadth of info that is presented there.

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>    Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: node-compact.png, node-details.png, node-hostcolumn.png, 
> node-toggle-row-numdocs.png, nodes-tab-real.png, nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16462295#comment-16462295
 ] 

Upayavira commented on SOLR-8207:
-

Looking great!

A few thoughts.
 * You clearly have a table in there. Have you looked at making it responsive?
 * Rather than having a 'detail' check box, could you make clicking on a row 
expand that row's detail?
 * Are the references to collections and cores clickable? Would be great if 
they could take you to that collection or core on the relevant host directly

Otherwise, looking really good!

 

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>    Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: node-compact.png, node-details.png, nodes-tab-real.png, 
> nodes-tab.png
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12276) Admin UI - Convert from "AngularJS" to "Angular"

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16459700#comment-16459700
 ] 

Upayavira commented on SOLR-12276:
--

[~jdyer] I'm not following Solr much at the moment, but it is great to see this 
ticket! If there is anything you need explaining regarding the original Angular 
UI, feel free to ask.

> Admin UI - Convert from "AngularJS" to "Angular"
> 
>
> Key: SOLR-12276
> URL: https://issues.apache.org/jira/browse/SOLR-12276
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: James Dyer
>Priority: Minor
>  Labels: Angular, AngularJS, angular-migration
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> With SOLR-12196 it was noted the current Solr Admin UI runs AngularJS (1.x), 
> which is to be End-of-Life later this year.  Various options were proposed 
> for what to do next.  One option is to keep the existing functionality but 
> migrate to a newer UI framework.  This ticket is to migrate the existing UI 
> to Angular (2+).
> See [this readme 
> file|https://github.com/jdyer1/lucene-solr/tree/feature/angular-conversion-solr-admin/solr/webapp].



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Next steps for Solr Admin UI - request for in-depth discussion

[Upayavira]

On Mon, 16 Apr 2018, at 6:53 PM, Alexandre Rafalovitch wrote:
> > It really depends on what your goal is: a refreshed UI or getting rid of 
> > AngularJS
> 
> I think that's an interesting question. Do we _know_ how a refreshed
> UI could be better than what we have now?
> *) Better mobile UI was one suggestion
> *) Reviewing it myself, I feel that there is lack of clarity whether
> some information/operation is Global, Collection-level, Core-level, or
> node-level. E.g. "Dashboard, java properties and thread dumps" are
> actually node level, next to Cloud, Collections and Suggestions that
> are global level. Next to logging, which I am guessing is a node
> level.
> *) Query screen had a number of requests against it, especially in
> regards to newer features
> *) Pluggable UI (e.g. for DIH) was a request and other plugins
> (/browse?) would probably enjoy a hook too (though it did not work out
> with admin-extra.html so much)
> 
> Because that's the first question a "UI designer from somewhere" will
> ask, even if we could have an access to one.

It is worth noting the heritage of the current UI. It was a reworking of the 
old, ugly JSP admin UI in 3.x. It more or less took the same pages and made 
them (much) more beautiful.

Then the angular one took that and gave it a newer backend. And then 
collections awareness was added.

Each of these were additive, leading to a little bit of an architectural mess.

So I think you are right - the first step is one of information architecture - 
how do we present all the details. That could then be presented to a UI 
designer if we found one. And one might be easier to find if we had the 
architecture.

Not only that, it might be possible to start building using something like 
Bootstrap or MaterialUI, and style it later - i.e. just following conventions 
rather than doing 'design'.

Upayavira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12196) Prepare Admin UI for migrating to Angular.io

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16439138#comment-16439138
 ] 

Upayavira commented on SOLR-12196:
--

{quote}If I had the knowledge, I'd be interested in helping with a rewrite. I 
just don't know enough about javascript or css to tackle a job like that.
{quote}
Then learn it :) It is great fun! I'm not a front-end developer by any means, I 
just learned what a colleague pointed me at. And there is structure there in 
the JavaScript land that wasn't there before that lends itself to back-end 
developers.

Go do a react tutorial or two. The CSS stuff we would defer to a graphic 
designer. In the end, it is just programming. I might be able to muster the 
time to put together a framework and build system onto which others can hang 
pages, especially if we already had a design put together.

> Prepare Admin UI for migrating to Angular.io
> 
>
> Key: SOLR-12196
> URL: https://issues.apache.org/jira/browse/SOLR-12196
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: Angular, AngularJS, angular-migration
> Fix For: master (8.0)
>
>
> AngularJS is soon end of life, it [enters LTS in july 
> 2018|https://docs.angularjs.org/misc/version-support-status], whereupon it 
> will only receive fixes to serious bugs. Solr uses AngularJS 1.3 (the latest 
> AngularJS will be 1.7).
> This issue is *not* for upgrading to Angular5/6, but to start preparing the 
> existing UI for easier migration later on. See 
> [https://angular.io/guide/upgrade].
> This JIRA will likely get multiple sub tasks such as
>  * Change to [Folders-by-Feature 
> Structure|https://angular.io/guide/upgrade#follow-the-angularjs-style-guide], 
> i.e. mix html, css, js in a folder based on feature
>  * Use a [Module 
> Loader|https://angular.io/guide/upgrade#using-a-module-loader] like 
> [Webpack|https://webpack.js.org/]
>  * Use [Component 
> Directives|https://angular.io/guide/upgrade#using-component-directives] 
> (requires first move from AngularJS 1.3 to 1.5)
> The rationale for this lira is recognising how central the Admin UI is to 
> Solr, not letting it rot on top of a dying framework. Better to start moving 
> step by step and [perhaps write all new views in Angular 
> 5|https://angular.io/guide/upgrade#upgrading-with-ngupgrade], than to fall 
> further and further behind.
> This effort of course assumes that Angular.io is the path we want to go, and 
> not React, VueJS or some other new kid on the block :)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16438866#comment-16438866
 ] 

Upayavira commented on SOLR-8207:
-

Your third option seems best to me. You don't want to explicitly proxy. You 
want to ask your local node for information that it happens to need to get from 
other nodes, but that happens behind the scenes, based upon a node name.

> Modernise cloud tab on Admin UI
> ---
>
> Key: SOLR-8207
> URL: https://issues.apache.org/jira/browse/SOLR-8207
> Project: Solr
>  Issue Type: Improvement
>  Components: Admin UI
>Affects Versions: 5.3
>    Reporter: Upayavira
>Assignee: Jan Høydahl
>Priority: Major
> Attachments: nodes-tab.png
>
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was 
> making real use of SolrCloud, and when we didn't really know the use-cases we 
> would need to support. I would argue that, whilst they are pretty (and 
> clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with 
> many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and 
> their associated replicas/collections. From this view, it would be possible 
> to add/remove replicas and to see the status of nodes. It would also be 
> possible to filter nodes by status: "show me only up nodes", "show me nodes 
> that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission 
> node" option, that would ensure that no replicas on this node are leaders, 
> and then remove all replicas from the node, ready for it to be removed from 
> the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Next steps for Solr Admin UI - request for in-depth discussion

[Upayavira]

Jan,

The plus of the Angular upgrade path that I saw you mention elsewhere
was that you could have both old and new Angulars running in the same
app, and migrate slowly. That would work for a change of backend, using
the same styling.
It really depends on what your goal is: a refreshed UI or getting rid of
AngularJS.
My aim was to keep the UI the same as this gave a very clear way to
validate success. If you change the UI at the same time, identifying
success becomes harder.
Also, replacing the backend without changing the UI is quite possible
with limited graphic design skills. Modernising the UI would require a
different set of skills, and would probably involve us bringing in a UI
designer from somewhere to give us mocked-up components to start from.
So really, the question as to how best to do it will likely depend on
who is doing the work.
Upayavira

On Sun, 15 Apr 2018, at 6:13 PM, Jan Høydahl wrote:
> Just to be clear, Angular is now also built on components, transpiled
> and a rich toolset, including debugger, unit testing, end-to-end
> tests, CLI with scaffolding for adding new components/services etc.> 
> Building using components will also help prepare the new UI for a
> plugin architecture where Solr contribs/plug-ins add their own UI menu
> items and screens dynamically (dynamic loading vs build-time
> compiling).> 
> The old UI grows with more screens and features week by week so the
> burden of switching does not become smaller if we wait.> 
> Upayavira, moving from jQuery to AngularJS took the approach of
> building a clean parallel  code base, with the downside of years of
> maintaining two UIs. Do you see any better approach this time around?> 
> Jan
> 
> Sendt fra min iPhone
> 
> 15. apr. 2018 kl. 14:20 skrev Upayavira <u...@odoko.co.uk>:
>> 
>> 
>> On Sat, 14 Apr 2018, at 4:40 PM, Alexandre Rafalovitch wrote:
>>> Hello,
>>>
>>> The relevant JIRA is SOLR-12196, but we felt this deserved a greater
>>> discussion.
>>>
>>> Basically, our Admin UI is currently using AngularJS (1.x) as its
>>> Javascript framework. That particular library has reached its
>>> evolutionary end long time ago and is about to stop being supported
>>> all together. The later versions of Angular carry the same name, but
>>> are _very_ _very_ different. So, despite the heroic efforts that got
>>> us here, we are facing this choice again. Also, as we were just
>>> trying to migrate the UI and not rethink it, the underlying
>>> design/file layout/plugin architecture is also quite problematic.
>>>
>>> The question is what is the right thing to do next. There are
>>> basically four options:
>>> 1) Migrate to the latest Angular in an incremental fashion (as per
>>>JIRA's original proposal)
>>> 2) Jump to a different library (such as React or Vue) which got a
>>>much stronger momentum and ecosystem these days, but sort of keep
>>>current architecture (UI feel/approach)
>>> 3) Go blue-sky with new library and actually put some deep thought
>>>into modern UI leveraging Solr's current features (Management
>>>API, JSON, etc). Also, by picking React (for example) we get
>>>access to the ecosystem of modern tools, extensions and even
>>>potentially mobile apps.
>>> 4) Drop our own UI and adopt somebody else's (I don't have any good
>>>suggestions here though)?
>>>
>>> Normally, option 1 would be the sane one. The challenge is two fold
>>> though:
>>> a) Even option 1 is a lot of work due the Angular team's radical
>>>change of direction. Enough that it will lock us out from any
>>>other option for at least another 3-4 years.
>>> b) We are all server-side developers. So, even the simple Javascript
>>>things are hard for us, never mind the CSS part. So, this makes
>>>the cost of starting with any new approach dis-proportionally
>>>hard. Once going, it is a bit easier, because the advanced
>>>concepts are similar to other languages.
>>>
>>> All of these, combined with all the open JIRAs on Admin issues
>>> - to me
>>> - make option 3 less crazy than usual.
>>>
>>> What do others think? Is there discontent with the current state of
>>> Admin UI (apart from the implementation choice)? Are there secret
>>> web designers here, willing to get us over a bump of migration? Is
>>> there a company out there, willing to sponsor relevant skills to let
>>> us leapfrog the incremental upgrade (similar to how we got the
>>> Reference Guide).>> 
>&g

Re: Next steps for Solr Admin UI - request for in-depth discussion

[Upayavira]

On Sat, 14 Apr 2018, at 4:40 PM, Alexandre Rafalovitch wrote:
> Hello,
> 
> The relevant JIRA is SOLR-12196, but we felt this deserved a greater 
> discussion.
> 
> Basically, our Admin UI is currently using AngularJS (1.x) as its
> Javascript framework. That particular library has reached its
> evolutionary end long time ago and is about to stop being supported
> all together. The later versions of Angular carry the same name, but
> are _very_ _very_ different. So, despite the heroic efforts that got
> us here, we are facing this choice again. Also, as we were just trying
> to migrate the UI and not rethink it, the underlying design/file
> layout/plugin architecture is also quite problematic.
> 
> The question is what is the right thing to do next. There are
> basically four options:
> 1) Migrate to the latest Angular in an incremental fashion (as per
> JIRA's original proposal)
> 2) Jump to a different library (such as React or Vue) which got a much
> stronger momentum and ecosystem these days, but sort of keep current
> architecture (UI feel/approach)
> 3) Go blue-sky with new library and actually put some deep thought
> into modern UI leveraging Solr's current features (Management API,
> JSON, etc). Also, by picking React (for example) we get access to the
> ecosystem of modern tools, extensions and even potentially mobile
> apps.
> 4) Drop our own UI and adopt somebody else's (I don't have any good
> suggestions here though)?
> 
> Normally, option 1 would be the sane one. The challenge is two fold though:
> a) Even option 1 is a lot of work due the Angular team's radical
> change of direction. Enough that it will lock us out from any other
> option for at least another 3-4 years.
> b) We are all server-side developers. So, even the simple Javascript
> things are hard for us, never mind the CSS part. So, this makes the
> cost of starting with any new approach dis-proportionally hard. Once
> going, it is a bit easier, because the advanced concepts are similar
> to other languages.
> 
> All of these, combined with all the open JIRAs on Admin issues - to me
> - make option 3 less crazy than usual.
> 
> What do others think? Is there discontent with the current state of
> Admin UI (apart from the implementation choice)? Are there secret web
> designers here, willing to get us over a bump of migration? Is there a
> company out there, willing to sponsor relevant skills to let us
> leapfrog the incremental upgrade (similar to how we got the Reference
> Guide).

As you know, I'm responsible for the current UI. The aims in building this 
version of the UI were to keep the visuals entirely the same, whilst reducing 
the size and complexity of the underlying JavaScript (we reduced it by about 
50% in terms of LoC). The bulk of the work in its implementation was in terms 
of understanding the intent of the existing code. Reproducing it in new code 
was a smaller task by comparison. I hope this will pay off in any future 
rewrite.

At the time, the JavaScript landscape was changing fast. It was clear that 
anything we produced would only be valid for a number of years. It seems we 
have now reached that limit.

I have recently taught myself basic ReactJS. It is clearly a powerful beast. 
The two major distinguishing factors from the current UI are its componentised 
nature (which means you don't build pages, you build re-usable components) and 
that it uses a transpiled language. 

To rebuild the current UI in React, we would need to decompose the HTML pages 
into components, and migrate behaviour into those components.

Using a transpiled language (and all the tools that support that, e.g. webpack) 
would give us a more compact, and modern, UI.

However, the HTML is growing old. It isn't properly responsive, and it doesn't 
use idioms that people have come to expect from a UI (e.g. no hamburgers).

In theory, I would support a rewrite of the visuals - it would make Solr seem 
more modern. However, I do not underestimate the amount of work involved.

Upayavira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-12196) Prepare Admin UI for migrating to Angular.io

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-12196?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16428448#comment-16428448
 ] 

Upayavira commented on SOLR-12196:
--

I don't have a major investment in Solr at this time, but I am certainly game 
to follow on and add what bits I might. Whilst I am far from a front-end 
developer, I have recently played with Webpack and React with some success. The 
transition from the old JS UI to Angular was made simpler because of how 
Angular manages its (whole page) templates. React breaks things down into 
smaller components, and whilst this could be better in the long run in terms of 
component reuse, it means that a conversion could be a substantial piece of 
work. I like your idea of breaking the task down into smaller steps.

> Prepare Admin UI for migrating to Angular.io
> 
>
> Key: SOLR-12196
> URL: https://issues.apache.org/jira/browse/SOLR-12196
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
>Priority: Major
>  Labels: Angular, AngularJS, angular-migration
> Fix For: master (8.0)
>
>
> AngularJS is soon end of life, it [enters LTS in july 
> 2018|https://docs.angularjs.org/misc/version-support-status], whereupon it 
> will only receive fixes to serious bugs. Solr uses AngularJS 1.3 (the latest 
> AngularJS will be 1.7).
> This issue is *not* for upgrading to Angular5/6, but to start preparing the 
> existing UI for easier migration later on. See 
> [https://angular.io/guide/upgrade].
> This JIRA will likely get multiple sub tasks such as
>  * Change to [Folders-by-Feature 
> Structure|https://angular.io/guide/upgrade#follow-the-angularjs-style-guide], 
> i.e. mix html, css, js in a folder based on feature
>  * Use a [Module 
> Loader|https://angular.io/guide/upgrade#using-a-module-loader] like 
> [Webpack|https://webpack.js.org/]
>  * Use [Component 
> Directives|https://angular.io/guide/upgrade#using-component-directives] 
> (requires first move from AngularJS 1.3 to 1.5)
> The rationale for this lira is recognising how central the Admin UI is to 
> Solr, not letting it rot on top of a dying framework. Better to start moving 
> step by step and [perhaps write all new views in Angular 
> 5|https://angular.io/guide/upgrade#upgrading-with-ngupgrade], than to fall 
> further and further behind.
> This effort of course assumes that Angular.io is the path we want to go, and 
> not React, VueJS or some other new kid on the block :)



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7896) Add a login page for Solr Administrative Interface

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7896?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16419281#comment-16419281
 ] 

Upayavira commented on SOLR-7896:
-

Let's just be clear what we are talking about here.

The Admin UI is a set of HTML and JS files.

It makes use of a set of APIs, that are typically JSON over HTTP: the same APIs 
as end users use.

So talking about one auth for the UI and one for the API doesn't entirely make 
sense. Serving the UI files up over a different auth scheme may be possible, 
but without the APIs they are pretty darn useless, no?

So what are we actually talking about here?

> Add a login page for Solr Administrative Interface
> --
>
> Key: SOLR-7896
> URL: https://issues.apache.org/jira/browse/SOLR-7896
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI, security
>Affects Versions: 5.2.1
>Reporter: Aaron Greenspan
>Priority: Major
>  Labels: authentication, login, password
>
> Out of the box, the Solr Administrative interface should require a password 
> that the user is required to set.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-11296) Spellcheck parameters not working in new UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-11296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16146866#comment-16146866
 ] 

Upayavira commented on SOLR-11296:
--

Not got a working setup nor time to investigate much, but I bet you the issue 
is this:

Those values all look to me like booleans, and they are not initialised. So 
going to this file:

https://github.com/apache/lucene-solr/blob/master/solr/webapp/web/js/angular/controllers/query.js

Go to line 30:

$scope.spellcheck = {spellcheck:"on"};

Replace this with:

$scope.spellcheck = {spellcheck:"on", "spellcheck.build": "off", 
"spellcheck.reload": "off", "spellcheck.onlyMorePopular": "off", . for all 
the above params

And then I suspect it will work. 

> Spellcheck parameters not working in new UI
> ---
>
> Key: SOLR-11296
> URL: https://issues.apache.org/jira/browse/SOLR-11296
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 7.0, 6.6.0, 6.3.0
>Reporter: Shawn Heisey
>
> When these spellcheck options are chosen in the query interface in the new 
> UI, they are not added to the query that gets executed:
> spellcheck.build
> spellcheck.reload
> spellcheck.onlyMorePopular
> spellcheck.extendedResults
> spellcheck.collate
> From what I could tell, the other spellcheck options *are* included in the 
> query when they are configured in the query interface.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Shorter URLs to Solr ref-guide?

[Upayavira]

If you do want to register a new domain, I suggest getting the Infrastructure 
team to do it (an INFRA ticket?) and point it at a requisite location. It will 
likely be easier to do it that way, so that the ASF owns the domain name from 
the get go.
Upayavira

On Mon, 10 Jul 2017, at 09:56 AM, Jan Høydahl wrote:
>> #2 (write script to shorten redundant page names in anchor names) is 
>> especially needed.> 
> There may be a plan to auto redirect Confluence links to the new guide, see 
> https://issues.apache.org/jira/browse/SOLR-10595> and if someone clicks a 
> link with an anchor, the redirect will not manage to scroll to correct sub 
> heading if we change every single> anchor. But the redirect will get to the 
> correct page, which is probably good enough.> 
> I haven’t thought through the redirect/alias part very much yet. The idea 
> would be that you could add an alias with a commit> to the guide itself, not 
> introducing any .htaccess, servlets or other things. If we used Javascript 
> for the redirect, then perhaps> we could have a format such as 
> http://solr.guide/s.html#schema and have the JS parse the string after # and 
> change .location ?> 
> *Idea #4: *
> Provide an icon next to every header, that will generate a 
> version-independent link, i.e. a link without “/6_6“ in it. The> way the site 
> is setup now, omitting the version in the URL will redirect to that page in 
> the current version of the guide (htaccess?)> This is useful for links that 
> describe concepts, but is of course prone to page renames in the future, 
> unless we enforce a polify> that a page rename shall leave the old page.html 
> in place with a redirect?> 
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
> 
>> 10. jul. 2017 kl. 05.59 skrev David Smiley <david.w.smi...@gmail.com>:>> 
>> Your 3 proposals look excellent Jan!
>> 
>> #2 (write script to shorten redundant page names in anchor names) is 
>> especially needed.>> 
>> ~ David
>> 
>> On Sun, Jul 9, 2017 at 3:53 PM Jan Høydahl <jan@cominvent.com> wrote:>>> 
>> Hi,
>>> 
>>>  I started to replace old wiki.apache.org/solr and cwiki.apache.org/solr 
>>> links to point to relevant>>>  sections in the new online Reference Guide 
>>> lucene.apache.org/solr/guide/ and discover pretty soon>>>  that the URLs 
>>> for the new guide are pretty long, e.g:
>>> 
>>>  Wiki:
>>>http://wiki.apache.org/solr/SchemaXml#Similarity
>>>  Cwiki:
>>>
>>> https://cwiki.apache.org/confluence/display/solr/Other+Schema+Elements#OtherSchemaElements-Similarity>>>
>>>   New ref-guide:
>>>
>>> http://lucene.apache.org/solr/guide/other-schema-elements.html#OtherSchemaElements-Similarity>>>
>>>  
>>> 
>>>  There are several things to note here:
>>>  * Long domain and prefix: http://lucene.apache.org/solr/guide/
>>>  * The anchor name typically repeats the page name: 
>>> other-schema-elements.html # OtherSchemaElements-Similarity>>>This is a 
>>> legacy from how Confluence auto generated anchors
>>> 
>>>  Since ref-guide is the main goto-docs for Solr I’d like the URLs to be as 
>>> short as possible, preferable>>>  so that you can remember the most 
>>> prominent pages and type them by hand, and that they can easily be 
>>> pasted>>>  into a flowing text without always breaking to the next line 
>>> because they are too long.>>> 
>>>  Proposals:
>>>  1. Register a domain for the guide, e.g. http://solr.guide/ — 12 chars 
>>> instead of 30 ($35/yr)>>>  2. Write a script that removes the duplicate 
>>> names in anchors, and run a one-time conversion>>> e.g. converts 
>>> #OtherSchemaElements-Similarity to #Similarity
>>>  3. Introduce a shortcut page for the refGuide, to create shortcuts for the 
>>> most frequently used>>> guide locations, e.g. create a page s.adoc that 
>>> contains a long list of short-links and a Javascript>>> that performs a 
>>> redirect. Example:
>>> http://solr.guide/s/schema.html ==> 
>>> http://solr.guide/6_6/documents-fields-and-schema-design.html>>> 
>>>  Just throwing this out here before creating JIRAs. What do you think?>>> 
>>>  --
>>>  Jan Høydahl, search solution architect
>>>  Cominvent AS - www.cominvent.com[1]
>>> 
>>> 
>>>  ->>>  
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>  For additional commands, e-mail: dev-h...@lucene.apache.org
>>> 
>> -- 
>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker>> 
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: 
>> http://www.solrenterprisesearchserver.com[2]

Links:

  1. http://www.cominvent.com/
  2. http://www.solrenterprisesearchserver.com/

[jira] [Commented] (SOLR-10042) Delete old deprecated Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16017204#comment-16017204
 ] 

Upayavira commented on SOLR-10042:
--

SOLR-10042_remove_commented.patch removes stuff that was meant to remind me of 
unimplemented features. I eventually stopped using that method, but failed to 
clean up. These comments are redundant and can be removed.

> Delete old deprecated Admin UI
> --
>
> Key: SOLR-10042
> URL: https://issues.apache.org/jira/browse/SOLR-10042
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: master (7.0)
>
> Attachments: SOLR-10042.patch, SOLR-10042_remove_commented.patch
>
>
> The old jQuery based Admin UI has been deprecated since 6.0. Let us clean up 
> the last known bugs in Angular UI and simply delete the old UI in  master.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: SolrCloud "master mode" planned?

[Upayavira]

On Wed, 26 Apr 2017, at 10:06 PM, David Smiley wrote:
> 
>> On Apr 26, 2017, at 4:35 PM, Upayavira <u...@odoko.co.uk> wrote:
>> 
>> I have done a *lot* of automating this. Redoing it recently it was
>> quite embarrassing to realise how much complexity there is involved
>> in it - it is crazy hard to get a basic, production ready SolrCloud
>> setup running.> 
> Would you mind enumerating a list of what sort of issues you ran into
> deploying ZooKeeper in a production config?  A quick draft list of
> sorts just to get a sense of what sort of stuff generally you had to
> contend with.  I recently did it in a Docker/Kontena infrastructure.
> I did not find it to be hard; maybe medium :-).  I got the nodes
> working out of the box with minimal effort but had to make changes to
> harden it.> * I found the existing official Docker image for Zookeeper 
> lacking in
>   that I couldn't easily specify the "auto purge" settings, which
>   default to no purging which is unacceptable.> * I set 
> "-XX:+CrashOnOutOfMemoryError" so that the process would end
>   when an OOM occurs so that Kontena (Docker orchestrator) would
>   notice its down so it could restart it (a rare event obviously).
>   Users not using a container environment might not care about this I
>   guess.  This was merely a configuration setting; no Docker image
>   hack needed.> * I also ensured I used the latest ZK 3.4.6 release I 
> recall 3.4.4
>   (or maybe even 3.4.5?) cached DNS entries without re-looking up if
>   it failed which is particularly problematic in a container
>   environment where it's common for services to get a new IP when they
>   are restarted.  Thankfully I did not learn that issue the hard way;
>   I recall a blog warning of this issue by Shalin or Martijn Koster.
>   No action from me here other than ensuring I used an appropriate new
>   version.  Originally out of laziness I used Confluent's Docker image
>   but I knew I would have to switch because of this issue.
I used it for a test case for an app I built when learning more about
deployments. It is all on github at
http://github.com/odoko-devops/uberstack. There's an example there in
examples/apache-solr. I gave up on that effort because (a) I was making
it more complex than it needed to be and (b) I couldn't compete with the
big guns in the devops industry.
What I needed was to have three ZooKeeper nodes start up and
autodiscover each other. That, I handled with Exhibitor (from Netflix).
They provide a (not-production ready!!) Docker image that, whilst it
takes a few minutes, does result in ZK nodes that are working as an
ensemble, when none of them know about each other to start. It requires
an S3 bucket to provide the co-ordination.
The real lesson was "don't fail, retry". I built a wrapper around Solr
so that if ZK wasn't available (and in the correct ensemble) Solr
wouldn't start yet. It just kept retrying. Similarly, In
https://github.com/odoko-devops/solr-utils there's a tool that, when
containerised, will allow you to create a chroot (must be done after ZK
but before Solr), to upload configs (must be done after Solr, but
before collection creation), create a collection (only once configs
present), etc.
It made use of Rancher to provide an overlay network with DNS used for
service discovery - the ZK nodes were accessible to Solr via the
hostname "zookeeper", so Solr didn't have to do anything fancy in order
to find them.
The outcome of this was a reliable one-click install of three ZK nodes,
three Solr cloud nodes, and indexed content and a webapp showing the
content. Was pretty cool.
Or should I say, the outcome was cool, the process to get there
was painful.
Happy to share more of this if it is useful.

Upayavira

>> One thing that is hard is getting a ZooKeeper ensemble going - using
>> Exhibitor makes it much easier.>> 
>> Something that has often occurred to me is, why do we require people
>> to go download a separate ZooKeeper, and work out how to install and
>> configure it, when we have it embedded already? Why can't we just
>> have a 'bin/solr zk start' command which starts an "embedded"
>> zookeeper, but without Solr. To really make it neat, we offer some
>> way (a la Exhibitor) for multiple concurrently started ZK nodes to
>> autodiscover each other, then getting our three ZK nodes up won't be
>> quite so treacherous.> 
> I've often thought the same -- why not just embed it.  People say it's
> not a "production config" but this is only because we all keep telling
> us this is in an echo chamber and we believe ourselves :-P> 
> ~ David
> 
>> 
>> On Wed, 26 Apr 2017, at 03:58 PM, Mike Drob wrote:
>>> Could the zk role also be guaranteed to ru

Re: SolrCloud "master mode" planned?

[Upayavira]

I have done a *lot* of automating this. Redoing it recently it was quite
embarrassing to realise how much complexity there is involved in it - it
is crazy hard to get a basic, production ready SolrCloud setup running.
One thing that is hard is getting a ZooKeeper ensemble going - using
Exhibitor makes it much easier.
Something that has often occurred to me is, why do we require people to
go download a separate ZooKeeper, and work out how to install and
configure it, when we have it embedded already? Why can't we just have a
'bin/solr zk start' command which starts an "embedded" zookeeper, but
without Solr. To really make it neat, we offer some way (a la Exhibitor)
for multiple concurrently started ZK nodes to autodiscover each other,
then getting our three ZK nodes up won't be quite so treacherous.
Just a thought.

Upayavira

On Wed, 26 Apr 2017, at 03:58 PM, Mike Drob wrote:
> Could the zk role also be guaranteed to run the Overseer (and no
> collections)? If we already have that separated out, it would make
> sense to put it with the embedded zk. I think you can already
> configure and place things manually this way, but it would be a huge
> win to package it all up nicely for users and set it to turnkey
> operation.> 
> I think it was a great improvement for deployment when we dropped
> tomcat, this is the next logical step.> 
> Mike
> 
> On Wed, Apr 26, 2017, 4:22 AM Jan Høydahl
> <jan@cominvent.com> wrote:>> There have been suggestions to add a “node 
> controller” process which
>> again could start Solr and perhaps ZK on a node.>> 
>> But adding a new “zk” role which would let that node start (embedded)
>> ZK I cannot recall. It would of course make a deploy simpler if ZK
>> was hidden as a solr role/feature and perhaps assigned to N nodes,
>> moved if needed etc. If I’m not mistaken ZK 3.5 would make such more
>> dynamic setups easier but is currently in beta.>> 
>> Also, in these days of containers, I kind of like the concept of
>> spinning up N ZK containers that the Solr containers connect to and
>> let Kubernetes or whatever you use take care of placement, versions
>> etc. So perhaps the need for a production-ready solr-managed zk is
>> not as big as it used to be, or maybe even undesirable? For
>> production Windows installs I could still clearly see a need though.>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>>> 25. apr. 2017 kl. 23.30 skrev Ishan Chattopadhyaya
>>> <ichattopadhy...@gmail.com>:>>> 
>>> Hi Otis,
>>> I've been working on, and shall be working on, a few issues on the
>>> lines of "hide ZK".>>> 
>>> SOLR-6736: Uploading configsets can now be done through Solr nodes
>>> instead of uploading them to ZK.>>> SOLR-10272: Use a _default configset, 
>>> with the intention of not
>>> needing the user to bother about the concept of configsets unless he
>>> needs to>>> SOLR-10446 (SOLR-9057): User can use CloudSolrClient without
>>> access to ZK>>> SOLR-8440: Enabling BasicAuth security through bin/solr 
>>> script
>>> Ability to edit security.json through the bin/solr script
>>> Having all this in place, and perhaps some more that I may be
>>> missing, should hopefully not need the user to know much about ZK.>>> 
>>> 1. Do you have suggestions on what more needs to be done for "hiding
>>>ZK"?>>> 2. Do you have suggestions on how to track this overall theme of
>>>"hiding ZK"? Some of these issues I mentioned are associated with
>>>other epics, so I don't know if creating a "hiding ZK" epic and
>>>having these (and other issues) as sub-tasks is a good idea
>>>(maybe it is). Alternatively, how about tracking these (and other
>>>issues) using some label?>>> Regards,
>>> Ishan
>>> 
>>> 
>>> 
>>> On Wed, Apr 26, 2017 at 2:39 AM, Otis Gospodnetić
>>> <otis.gospodne...@gmail.com> wrote:>>>> Hi,
>>>> 
>>>> This thread about Solr master-slave vs. SolrCloud deployment poll
>>>> seems to point out people find SolrCloud (the ZK part of it)
>>>> deployment complex:>>>> 
>>>> http://search-lucene.com/m/Solr/eHNlfm4WpJPVR92?subj=Re+Poll+Master+Slave+or+SolrCloud+>>>>
>>>>  
>>>> It could be just how information is presented...
>>>> ... or how ZK is exposed as something external, which it is...
>>>> 
>>>> Are there plans to "hide ZK"?  Or maybe have the notion of master-
>>>> only (not as in master-slave, but as in running ZK only, not
>>>> hosting data) mode for SolrCloud nodes (a la ES)?>>>> 
>>>> I peeked at JIRA, but couldn't find anything about that, although I
>>>> seem to recall some mention of embedding ZK to make things easier
>>>> for SolrCloud users.  I think I saw that at some Lucene Revolution
>>>> talk?>>>> 
>>>> Thanks,
>>>> Otis
>>>> --
>>>> Monitoring - Log Management - Alerting - Anomaly Detection
>>>> Solr & Elasticsearch Consulting Support Training -
>>>> http://sematext.com/>>>> 

[jira] [Commented] (SOLR-8138) Simple UI for issuing SQL queries

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15947774#comment-15947774
 ] 

Upayavira commented on SOLR-8138:
-

Is the isbn field multivalued? I think it becomes an array when it is. It is 
important to be able to handle that situation, even if you have to tidy up the 
data in JS afterwards

> Simple UI for issuing SQL queries
> -
>
> Key: SOLR-8138
> URL: https://issues.apache.org/jira/browse/SOLR-8138
> Project: Solr
>  Issue Type: New Feature
>  Components: Admin UI
>Affects Versions: 6.0
>Reporter: Joel Bernstein
>Priority: Minor
> Attachments: SOLR-8138.patch
>
>
> It would be great for Solr 6 if we could have admin screen where we could 
> issue SQL queries using the new SQL interface.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10201) Admin UI: Add Collection "creates collection", "Connection to Solr lost", when replicationFactor>1

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15883133#comment-15883133
 ] 

Upayavira commented on SOLR-10201:
--

[~sarkaramr...@gmail.com] look at places where the doNotIntercept is set, and 
do the same. It seems it is set in the services, in services.js, so you could 
set it for certain tasks.

[~erickerickson] JS is inherently async anyway so you could have a "request 
submitted" and a "request complete" feedback without any substantial change in 
the code. To add a 'check status' button would require the backend calls to be 
async, which would be considerably more work, if they aren't async already.


> Admin UI: Add Collection "creates collection", "Connection to Solr lost", 
> when replicationFactor>1
> --
>
> Key: SOLR-10201
> URL: https://issues.apache.org/jira/browse/SOLR-10201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.2
>Reporter: Amrit Sarkar
> Attachments: screenshot-1.png
>
>
> "Add Collection" fails miserably when replicationFactor >1.
> There must be a better way to handle the request we are making through JS.
> PF screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10201) Admin UI: Add Collection "creates collection", "Connection to Solr lost", when replicationFactor>1

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882965#comment-15882965
 ] 

Upayavira commented on SOLR-10201:
--

The timeout is set for all components. See js/angular/app.js. see 
.factory('httpInterceptor'). That's where the timeout is set.

Also note, in that same method, doNotIntercept. This is an example of how an 
caller can signal a specific behaviour to the interceptor. So, you could have a 
doNotTimeout option that simply avoids setting the "connectionStatusInactive" 
timeout.

> Admin UI: Add Collection "creates collection", "Connection to Solr lost", 
> when replicationFactor>1
> --
>
> Key: SOLR-10201
> URL: https://issues.apache.org/jira/browse/SOLR-10201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.2
>Reporter: Amrit Sarkar
> Attachments: screenshot-1.png
>
>
> "Add Collection" fails miserably when replicationFactor >1.
> There must be a better way to handle the request we are making through JS.
> PF screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10201) Admin UI: Add Collection "creates collection", "Connection to Solr lost", when replicationFactor>1

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10201?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15882667#comment-15882667
 ] 

Upayavira commented on SOLR-10201:
--

This is generally due to the timeout. If a request takes longer than the 
timeout, it is assumed to imply that the server is down, which for long running 
requests isn't necessarily the case.

It would be great to add an option for certain HTTP requests to say "this may 
take a long time, don't set a timeout as you would normally".

> Admin UI: Add Collection "creates collection", "Connection to Solr lost", 
> when replicationFactor>1
> --
>
> Key: SOLR-10201
> URL: https://issues.apache.org/jira/browse/SOLR-10201
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: Admin UI
>Affects Versions: 6.2
>Reporter: Amrit Sarkar
> Attachments: screenshot-1.png
>
>
> "Add Collection" fails miserably when replicationFactor >1.
> There must be a better way to handle the request we are making through JS.
> PF screenshot.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9969) Display new metrics on the UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9969?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15838566#comment-15838566
 ] 

Upayavira commented on SOLR-9969:
-

[~tomasflobbe] one of the points of doing the conversion was to make the code 
more accessible to non-JS developers. I'm afraid I'm not doing Solr dev at the 
moment, but your patch looks simple - does it work?

> Display new metrics on the UI
> -
>
> Key: SOLR-9969
> URL: https://issues.apache.org/jira/browse/SOLR-9969
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: metrics
>Reporter: Varun Thacker
> Attachments: mbeans_handler.png, SOLR-9969.patch
>
>
> The current Core Selector -> Core -> Plugin/Stats UI shows tabs for the new 
> metrics information we are adding but doesn't populate correctly.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-10037) (non-original) Solr Admin UI > query tab > unexpected url above results

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15838528#comment-15838528
 ] 

Upayavira commented on SOLR-10037:
--

There is a ticket that takes the /solr out of URLs used in the services.js 
file, making them relative such that Solr might be deployed to a different URL. 
It looks like this might be an inadvertent consequence of that change. See 
SOLR-9584.

> (non-original) Solr Admin UI > query tab > unexpected url above results
> ---
>
> Key: SOLR-10037
> URL: https://issues.apache.org/jira/browse/SOLR-10037
> Project: Solr
>  Issue Type: Task
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Christine Poerschke
>Priority: Minor
>
> To reproduce, in a browser run a search from the query tab and then notice 
> the url shown above the results
> {code}
> # actual:   http://localhost:8983techproducts/select?indent=on=*:*=json
> # expected: 
> http://localhost:8983/solr/techproducts/select?q=*%3A*=json=true
> {code}
> (We had noticed this when using the (master branch) Admin UI during the 
> [London Lucene Hackday for Full 
> Fact|https://www.meetup.com/Apache-Lucene-Solr-London-User-Group/events/236356241/]
>  on Friday, I just tried to reproduce both on master (reproducible with 
> non-original version only) and on branch_6_4 (not reproducible) and search 
> for an existing open issue found no apparent match.)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9584) The absolute URL path in server/solr-webapp/webapp/js/angular/services.js would make context customization not work

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9584?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15814972#comment-15814972
 ] 

Upayavira commented on SOLR-9584:
-

The original intention of SOLR-9000 still stands. We didn't bother supporting 
non /solr paths, because Solr is moving away from being a webapp.

However, this particular patch is pretty innocuous, and doesn't appear to 
change much, so just like [~janhoy], I think this would be a reasonable patch 
to apply.

> The absolute URL path in server/solr-webapp/webapp/js/angular/services.js 
> would make context customization not work
> ---
>
> Key: SOLR-9584
> URL: https://issues.apache.org/jira/browse/SOLR-9584
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Affects Versions: 6.2
>Reporter: Yun Jie Zhou
>Priority: Minor
>  Labels: patch
>
> The absolute path starting from /solr in 
> server/solr-webapp/webapp/js/angular/services.js would make the context 
> customization not work.
> For example, we should use $resource('admin/info/system', {"wt":"json", 
> "_":Date.now()}); instead of $resource('/solr/admin/info/system', 
> {"wt":"json", "_":Date.now()});



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9732) Field dropdown in Schema Browser screen can overlap field name in smaller browser windows

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15686656#comment-15686656
 ] 

Upayavira commented on SOLR-9732:
-

A 'select' element uses the 'chosen' library. This library replaces the HTML 
select element with some HTML that constructs a prettier, and more functional, 
drop down. Thus, if you apply your sizing to the HTML select element, you are 
effectively sizing an invisible (hidden) element, which ain't gonna help. You 
will want to look for other uses of select with a 'chosen' attribute and see 
where the width has been applied. I can't remember where I have done it, but I 
know I have succeeded at setting widths on Chosen select elements before.

> Field dropdown in Schema Browser screen can overlap field name in smaller 
> browser windows
> -
>
> Key: SOLR-9732
> URL: https://issues.apache.org/jira/browse/SOLR-9732
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Affects Versions: 6.3
>Reporter: Cassandra Targett
>Assignee: Alexandre Rafalovitch
>Priority: Minor
> Attachments: FieldDropdown.png
>
>
> If I make my browser window smaller than say 1200px wide, the field selection 
> dropdown on the Schema Browser stays the same width while the content moves, 
> making it so the dropdown will overlap the field name.
> Probably easiest to see in the attached screenshot.
> This happens in both Chrome and Safari (I didn't check FF), but is seen at a 
> larger screen width in Chrome.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6082) Umbrella JIRA for Admin UI and SolrCloud.

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15503407#comment-15503407
 ] 

Upayavira commented on SOLR-6082:
-

[~mkhludnev] please create a separate ticket. The two UIs should be using the 
same back-end so should exhibit the same behaviour.

> Umbrella JIRA for Admin UI and SolrCloud.
> -
>
> Key: SOLR-6082
> URL: https://issues.apache.org/jira/browse/SOLR-6082
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.9, 6.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>
> It would be very helpful if the admin UI were more "cloud friendly". This is 
> an umbrella JIRA so we can collect sub-tasks as necessary. I think there 
> might be scattered JIRAs about this, let's link them in as we find them.
> [~steffkes] - I've taken the liberty of assigning it to you since you 
> expressed some interest. Feel free to assign it back if you want...
> Let's imagine that a user has a cluster with _no_ collections assigned and 
> start from there.
> Here's a simple way to set this up. Basically you follow the reference guide 
> tutorial but _don't_ define a collection.
> 1> completely delete the "collection1" directory from example
> 2> cp -r example example2
> 3> in example, execute "java -DzkRun -jar start.jar"
> 4> in example2, execute "java -Djetty.port=7574 -DzkHost=localhost:9983 -jar 
> start.jar"
> Now the "cloud link" appears. If you expand the tree view, you see the two 
> live nodes. But, there's nothing in the graph view, no cores are selectable, 
> etc.
> First problem (need to solve before any sub-jiras, so including it here): You 
> have to push a configuration directory to ZK.
> [~thetapi] The _last_ time Stefan and I started allowing files to be written 
> to Solr from the UI it was...unfortunate. I'm assuming that there's something 
> similar here. That is, we shouldn't allow pushing the Solr config _to_ 
> ZooKeeper through the Admin UI, where they'd be distributed to all the solr 
> nodes. Is that true? If this is a security issue, we can keep pushing the 
> config dirs to ZK a manual step for now...
> Once we determine how to get configurations up, we can work on the various 
> sub-jiras.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Closed] (SOLR-6082) Umbrella JIRA for Admin UI and SolrCloud.

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira closed SOLR-6082.
---

> Umbrella JIRA for Admin UI and SolrCloud.
> -
>
> Key: SOLR-6082
> URL: https://issues.apache.org/jira/browse/SOLR-6082
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.9, 6.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>
> It would be very helpful if the admin UI were more "cloud friendly". This is 
> an umbrella JIRA so we can collect sub-tasks as necessary. I think there 
> might be scattered JIRAs about this, let's link them in as we find them.
> [~steffkes] - I've taken the liberty of assigning it to you since you 
> expressed some interest. Feel free to assign it back if you want...
> Let's imagine that a user has a cluster with _no_ collections assigned and 
> start from there.
> Here's a simple way to set this up. Basically you follow the reference guide 
> tutorial but _don't_ define a collection.
> 1> completely delete the "collection1" directory from example
> 2> cp -r example example2
> 3> in example, execute "java -DzkRun -jar start.jar"
> 4> in example2, execute "java -Djetty.port=7574 -DzkHost=localhost:9983 -jar 
> start.jar"
> Now the "cloud link" appears. If you expand the tree view, you see the two 
> live nodes. But, there's nothing in the graph view, no cores are selectable, 
> etc.
> First problem (need to solve before any sub-jiras, so including it here): You 
> have to push a configuration directory to ZK.
> [~thetapi] The _last_ time Stefan and I started allowing files to be written 
> to Solr from the UI it was...unfortunate. I'm assuming that there's something 
> similar here. That is, we shouldn't allow pushing the Solr config _to_ 
> ZooKeeper through the Admin UI, where they'd be distributed to all the solr 
> nodes. Is that true? If this is a security issue, we can keep pushing the 
> config dirs to ZK a manual step for now...
> Once we determine how to get configurations up, we can work on the various 
> sub-jiras.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Resolved] (SOLR-6082) Umbrella JIRA for Admin UI and SolrCloud.

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira resolved SOLR-6082.
-
Resolution: Fixed

This ticket has served its purpose.

> Umbrella JIRA for Admin UI and SolrCloud.
> -
>
> Key: SOLR-6082
> URL: https://issues.apache.org/jira/browse/SOLR-6082
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.9, 6.0
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>
> It would be very helpful if the admin UI were more "cloud friendly". This is 
> an umbrella JIRA so we can collect sub-tasks as necessary. I think there 
> might be scattered JIRAs about this, let's link them in as we find them.
> [~steffkes] - I've taken the liberty of assigning it to you since you 
> expressed some interest. Feel free to assign it back if you want...
> Let's imagine that a user has a cluster with _no_ collections assigned and 
> start from there.
> Here's a simple way to set this up. Basically you follow the reference guide 
> tutorial but _don't_ define a collection.
> 1> completely delete the "collection1" directory from example
> 2> cp -r example example2
> 3> in example, execute "java -DzkRun -jar start.jar"
> 4> in example2, execute "java -Djetty.port=7574 -DzkHost=localhost:9983 -jar 
> start.jar"
> Now the "cloud link" appears. If you expand the tree view, you see the two 
> live nodes. But, there's nothing in the graph view, no cores are selectable, 
> etc.
> First problem (need to solve before any sub-jiras, so including it here): You 
> have to push a configuration directory to ZK.
> [~thetapi] The _last_ time Stefan and I started allowing files to be written 
> to Solr from the UI it was...unfortunate. I'm assuming that there's something 
> similar here. That is, we shouldn't allow pushing the Solr config _to_ 
> ZooKeeper through the Admin UI, where they'd be distributed to all the solr 
> nodes. Is that true? If this is a security issue, we can keep pushing the 
> config dirs to ZK a manual step for now...
> Once we determine how to get configurations up, we can work on the various 
> sub-jiras.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Is "solr.AnalyzerName" expansion supposed to work for Analyzers?

[Upayavira]

On Sat, 10 Sep 2016, at 04:03 PM, Uwe Schindler wrote:
> To add,
> 
> the manages schema really makes it easy to "rewrite". My plan would be:
> 
> - Add a new "type" or "name" attribute to schema.xml, which is contrary
> to "class" attribute usage
> - When a manages schema is loaded, the resolving of classes using the
> hack is done as it is now. Warnings are printed as said before.
> - The managed schema is then changes to switch to the new attribute
> (there is a getter to get the symbolic name from the factory, so
> rewriting is easy)
> 
> In addition, this simplifies usage: Some GUI could show a dropdown list
> for clicking together the analyzer. We just need to add a schema-REST
> endpoint to get all names.
> 
> Maybe open an issue targeted for 6.x / 7.0. I'd be happy to help to fix
> this, although I could only do the SolrResourceLoader and SolrAnalyzer
> stuff.

 Not knowing how to get a list of acceptable components was the thing
 that stopped me adding that part of the schema API to the admin UI. And
 API to tell you which components exist would be extremely helpful.

Upayavira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15445528#comment-15445528
 ] 

Upayavira commented on SOLR-9000:
-

See here: https://wiki.apache.org/solr/WhyNoWar

Solr does not support being used as a war in a different servlet container. It 
may work, it may not.

Therefore, as started above, the additional complexity required to support 
multiple roots has not been added to the UI.

If someone took the time to make it work, i wouldn't object, but i would be 
concerned if that led to people thinking Solr would work as a war. If it isn't 
this preventing it, it may soon be something else. And that something else 
could occur at any time.

I'd suggest you rearchitect your system to use the inbuilt jetty, as you will 
be following Standard practice at that point. If that requires two JVMs, so be 
it.

> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>Assignee: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g. 
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries 
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
>  bq.  default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
> 
>   ^/$
>   /solr6_0/instance/solr1/
>  
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually 
> loaded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9358) [AngularUI] In Cloud->Tree file view area, collapse metadata by default

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15401211#comment-15401211
 ] 

Upayavira commented on SOLR-9358:
-

That plus sign looks good to me. I'd just like us to use something that is 
consistent with the existing UI. Go for it!

> [AngularUI] In Cloud->Tree file view area, collapse metadata by default
> ---
>
> Key: SOLR-9358
> URL: https://issues.apache.org/jira/browse/SOLR-9358
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.2, master (7.0)
>
> Attachments: Metadata expanded.png, Metadata with arrow.png, Metadata 
> with plus.png, SOLR-9358-plusimg.patch, SOLR-9358.patch
>
>
> Spinoff from SOLR-8379
> In Cloud->Tree UI, the metadata section on top of file content takes up 
> valuable space. Suggest to collapse that part by default and make it possible 
> to expand on demand by clicking. That will avoid scrolling on small screens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9358) [AngularUI] In Cloud->Tree file view area, collapse metadata by default

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399073#comment-15399073
 ] 

Upayavira commented on SOLR-9358:
-

Regarding the unicode arrows, go look in the codebase, you'll find an images 
directory full of icons. I'm sure you'll find appropriate arrows in there that 
will give a consistent styling with the rest of the UI.

> [AngularUI] In Cloud->Tree file view area, collapse metadata by default
> ---
>
> Key: SOLR-9358
> URL: https://issues.apache.org/jira/browse/SOLR-9358
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.2, master (7.0)
>
> Attachments: Metadata expanded.png, Metadata with arrow.png, 
> SOLR-9358.patch
>
>
> Spinoff from SOLR-8379
> In Cloud->Tree UI, the metadata section on top of file content takes up 
> valuable space. Suggest to collapse that part by default and make it possible 
> to expand on demand by clicking. That will avoid scrolling on small screens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9358) [AngularUI] In Cloud->Tree file view area, collapse metadata by default

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15399070#comment-15399070
 ] 

Upayavira commented on SOLR-9358:
-

Absolutely. The metadata isn't something I've ever paid attention to - it is 
always the data that I want to see, so you have my blessing.

> [AngularUI] In Cloud->Tree file view area, collapse metadata by default
> ---
>
> Key: SOLR-9358
> URL: https://issues.apache.org/jira/browse/SOLR-9358
> Project: Solr
>  Issue Type: Improvement
>  Security Level: Public(Default Security Level. Issues are Public) 
>  Components: UI
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
> Fix For: 6.2, master (7.0)
>
> Attachments: Metadata expanded.png, Metadata with arrow.png, 
> SOLR-9358.patch
>
>
> Spinoff from SOLR-8379
> In Cloud->Tree UI, the metadata section on top of file content takes up 
> valuable space. Suggest to collapse that part by default and make it possible 
> to expand on demand by clicking. That will avoid scrolling on small screens.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4268) Admin UI - button to unload transient core without removing from solr.xml

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15390027#comment-15390027
 ] 

Upayavira commented on SOLR-4268:
-

[~erickerickson] I think you'll find that's already the case - the core admin 
tab doesn't appear if in cloud mode (on the new UI at least).

Strictly, this ticket is about the core admin *API* not the UI specifically, as 
the UI doesn't have the ability to do anything that you are talking about. I'd 
suggest changing this to an API ticket rather than a UI one.

> Admin UI - button to unload transient core without removing from solr.xml
> -
>
> Key: SOLR-4268
> URL: https://issues.apache.org/jira/browse/SOLR-4268
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 4.0
>Reporter: Shawn Heisey
> Fix For: 4.9, 6.0
>
>
> The core "unload" button in the UI currently will completely remove a core 
> from solr.xml.  With the implentation of transient cores, there should be a 
> way to ask Solr to unload a core without removing it entirely.
> This leads into a discussion about terminology.  UNLOAD isn't a good 
> single-word description for what it does.  A case could be made for having 
> REMOVE and DELETE actions for CoreAdmin, with confirmation prompts if you 
> click on those buttons in the UI.  DELETE could simply be an option on REMOVE 
> - which I think you can actually currently do with UNLOAD.
> Another idea, not sure if it needs its own issue or is part of this one: If a 
> core is mentioned in solr.xml but not actually loaded, it would be very cool 
> if it were listed, but with a different background color to indicate the 
> non-loaded state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-4157) Add more conventional search functionality to the Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-4157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15389344#comment-15389344
 ] 

Upayavira commented on SOLR-4157:
-

This was intended to be a new feature, going beyond the /browse interface. I'm 
not likely to get to it in the forseeable future so reasonable to close it.

> Add more conventional search functionality to the Admin UI
> --
>
> Key: SOLR-4157
> URL: https://issues.apache.org/jira/browse/SOLR-4157
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Reporter: Upayavira
>Priority: Minor
> Attachments: SOLR-4157.patch
>
>
> The admin UI has a 'query' pane which allows searching the index. However, 
> this is currently an 'expert' level feature, as you must specify exact 
> request parameters and interpret output XML or JSON. 
> I suggest we add simple versions of each. A simple query pane would give a 
> more conventional search interface for running queries. A simple results pane 
> would give HTML formatted results with features to nicely display 
> hightlighting, explains, etc.
> To give an idea of what this might look like, I've attached a rudimentary 
> patch that gives an HTML option for wt which formats the query results as 
> (somewhat minimal) HTML.
> The challenge will be in producing a search interface that is schema 
> agnostic, as to be really useful, it should work with any index, and not just 
> with the fields in the default schema (perhaps Erik Hatcher is right, this 
> should be backed by the velocityResponseWriter).
> Thoughts welcome.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9315) SchemaSimilarityFactory should delegate queryNorm and coord to the default similarity

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384407#comment-15384407
 ] 

Upayavira commented on SOLR-9315:
-

This patch did resolve my issue. How should we go about committing it?

I'm happy to commit it, but I wouldn't know how to provide a test for it.

> SchemaSimilarityFactory should delegate queryNorm and coord to the default 
> similarity
> -
>
> Key: SOLR-9315
> URL: https://issues.apache.org/jira/browse/SOLR-9315
> Project: Solr
>  Issue Type: Bug
>  Security Level: Public(Default Security Level. Issues are Public) 
>Reporter: Adrien Grand
>Priority: Minor
> Attachments: SOLR-9315.patch
>
>
> This is a follow-up to the discussion with [~upayavira] on LUCENE-6590: 
> SchemaSimilarityFactory can easily build similarities that apply the idf 
> twice.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15384402#comment-15384402
 ] 

Upayavira commented on LUCENE-6590:
---

I applied your patch and my problems went away. Many thanks!!

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15383180#comment-15383180
 ] 

Upayavira commented on LUCENE-6590:
---

I upgraded my Solr configs to match the 5.5, and the issue was still there. I 
eventually tracked down this snippet in Solr's SchemaSimilarityFactory.java:

{{
 * 
 * NOTE: Users should be aware that even when this factory uses a single 
default
 * Similarity for some or all fields in a Query, the behavior can 
be inconsistent
 * with the behavior of explicitly configuring that same 
Similarity globally, because
 * of differences in how some multi-field / multi-clause behavior is defined in
 * PerFieldSimilarityWrapper.  In particular please consider 
carefully the documentation
 *  implementation of {@link Similarity#coord} and {@link 
Similarity#queryNorm} in
 * {@link ClassicSimilarity} compared to {@link PerFieldSimilarityWrapper}
 * 
}}

which suggests that adding a SchemaSimilarityFactory will *change* the scoring, 
even if you continue to use the ClassicSimilarityFactory.


> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-7871) Platform independent config file instead of solr.in.sh and solr.in.cmd

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-7871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15359337#comment-15359337
 ] 

Upayavira commented on SOLR-7871:
-

If you make this look both in your config file, and also in environment 
variables, you will be able to take the functionality out of bin/solr, but 
maintain backwards compatibility. Also, I suspect that more and more 
applications will be expecting to be configured with environment variables 
given that is how Docker apps expect to be configured, so having both 
capabilities is valuable.

> Platform independent config file instead of solr.in.sh and solr.in.cmd
> --
>
> Key: SOLR-7871
> URL: https://issues.apache.org/jira/browse/SOLR-7871
> Project: Solr
>  Issue Type: Improvement
>  Components: scripts and tools
>Affects Versions: 5.2.1
>Reporter: Jan Høydahl
>Assignee: Jan Høydahl
>  Labels: bin/solr
> Fix For: 6.0
>
> Attachments: SOLR-7871.patch
>
>
> Spinoff from SOLR-7043
> The config files {{solr.in.sh}} and {{solr.in.cmd}} are currently executable 
> batch files, but all they do is to set environment variables for the start 
> scripts on the format {{key=value}}
> Suggest to instead have one central platform independent config file e.g. 
> {{bin/solr.yml}} or {{bin/solrstart.properties}} which is parsed by 
> {{SolrCLI.java}}.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9194) Enhance the bin/solr script to perform file operations to/from Zookeeper

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15348012#comment-15348012
 ] 

Upayavira commented on SOLR-9194:
-

Just a thought - am happy to be ignored:

Is Zookeeper essential to Solr? Should we be naming this option after 
Zookeeper, or rather are we uploading the configs to *Solr*, which happens to 
store them in ZK?

Thus:

{code}
solr config upload -d  -n  -z zkHost
solr config cp schema.xml solr:schema.xml
etc
{code}


> Enhance the bin/solr script to perform file operations to/from Zookeeper
> 
>
> Key: SOLR-9194
> URL: https://issues.apache.org/jira/browse/SOLR-9194
> Project: Solr
>  Issue Type: Improvement
>Reporter: Erick Erickson
>Assignee: Erick Erickson
>Priority: Minor
> Attachments: SOLR-9194.patch, SOLR-9194.patch
>
>
> There are a few other files that can reasonably be pushed to Zookeeper, e.g. 
> solr.xml, security.json, clusterprops.json. Who knows? Even 
> /state.json for the brave.
> This could reduce further the need for bouncing out to zkcli.
> Assigning to myself just so I don't lose track, but I would _love_ it if 
> someone else wanted to take it...
> I'm thinking the commands would be 
> bin/solr zk -putfile -z  -p  -f 
> bin/solr zk -getfile -z  -p  -f 
> but I'm not wedded to those, all suggestions welcome.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: How to implement BM25 in Lucene

[Upayavira]

Vitaly,

Please ask this on either the java-user or the solr-user list, depending
on your context. You will also need to provide more detail to your
question, as you haven't said enough for anyone to say much, other than
that BM25 is the default in Solr/Lucene 6.0+.

Upayavira

On Thu, 16 Jun 2016, at 08:58 PM, vitaly bulgakov wrote:
> Need help in implementing BM25 to replace a standard Lucene TF-IDF
> scoring. 
> 
> 
> 
> --
> View this message in context:
> http://lucene.472066.n3.nabble.com/How-to-implement-BM25-in-Lucene-tp4282727.html
> Sent from the Lucene - Java Developer mailing list archive at Nabble.com.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328467#comment-15328467
 ] 

Upayavira commented on LUCENE-6590:
---

It seems a previous test I did was flawed (I thought I was pushing updated 
configs, but suspect that I was actually pushing old ones). Scoring is now 
working correctly, the main change being an update of the Lucene match version 
from 4.6 to 5.5.

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328413#comment-15328413
 ] 

Upayavira commented on LUCENE-6590:
---

It is quite possibly something in my setup. I figured because someone else 
reported the same issue it might be more global, but I think now it is time for 
me to assume I've done something stupid. Apologies and thanks.

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15328207#comment-15328207
 ] 

Upayavira commented on LUCENE-6590:
---

Any ideas [~jpountz]

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324676#comment-15324676
 ] 

Upayavira commented on LUCENE-6590:
---

Here's an example for 4.10 and the same query against 5.5 - note, it is a 
different doc though:

{code}
4.10 score 
  "2937439": {
"match": true,
"value": 5.5993805,
"description": "weight(description:obama in 394012)
[DefaultSimilarity], result of:",
"details": [
  {
"match": true,
"value": 5.5993805,
"description": "fieldWeight in 394012, product of:",
"details": [
  {
"match": true,
"value": 1,
"description": "tf(freq=1.0), with freq of:",
"details": [
  {
"match": true,
"value": 1,
"description": "termFreq=1.0"
  }
]
  },
  {
"match": true,
"value": 5.5993805,
"description": "idf(docFreq=56010, maxDocs=5568765)"
  },
  {
"match": true,
"value": 1,
"description": "fieldNorm(doc=394012)"
  }
]
  }
]
5.5 score 
  "2502281":{
"match":true,
"value":28.51136,
"description":"weight(description:obama in 43472) [], result
of:",
"details":[{
"match":true,
"value":28.51136,
"description":"score(doc=43472,freq=1.0), product of:",
"details":[{
"match":true,
"value":5.339603,
"description":"queryWeight, product of:",
"details":[{
"match":true,
"value":5.339603,
"description":"idf(docFreq=31905,
maxDocs=2446459)"},
  {
"match":true,
"value":1.0,
"description":"queryNorm"}]},
  {
"match":true,
"value":5.339603,
"description":"fieldWeight in 43472, product of:",
"details":[{
"match":true,
"value":1.0,
"description":"tf(freq=1.0), with freq of:",
"details":[{
"match":true,
"value":1.0,
"description":"termFreq=1.0"}]},
  {
"match":true,
"value":5.339603,
"description":"idf(docFreq=31905,
maxDocs=2446459)"},
  {
"match":true,
"value":1.0,
"description":"fieldNorm(doc=43472)"}]}]}]},
{code}

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8993) New UI can't show DIH

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324668#comment-15324668
 ] 

Upayavira commented on SOLR-8993:
-

I have a serious lack of spare time at the moment, and on top of that, I've 
never used the DIH.

Please feel free to try and provide a patch, in the meantime.

> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: SOLR-8993.patch, SOLR6.png, screenshot-1.png, 
> screenshot-2.png, screenshot-3.png, screenshot-4.png, screenshot-5.png, 
> screenshot-6.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for 
> importing from database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324317#comment-15324317
 ] 

Upayavira commented on LUCENE-6590:
---

My schema explicitly specifies the ClassicSimilarity. My Lucene match version 
was 4.6. I increased it to 5.5 and the behaviour was the same (this is using a 
Solr 5.5 system).

I could try and knock up a test case, but to-date I've avoided coding in Java 
on Solr/Lucene, so not yet familiar with the various test frameworks.

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324150#comment-15324150
 ] 

Upayavira commented on LUCENE-6590:
---

My code in this case is just Solr, so it seems that in this change, the 
"normalize based on the value of getvalueForNormalization" wasn't done in Solr.

I've looked briefly at the SolrIndexSearcher, which subclasses IndexSearcher, 
but it doesn't seem to mess with normalization. Any chance you could take a 
look at SolrIndexSearcher and see if something was missed there? I'm definitely 
seeing scores which are tf*tf*idf in Solr results.



> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (LUCENE-6590) Explore different ways to apply boosts

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/LUCENE-6590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15324070#comment-15324070
 ] 

Upayavira commented on LUCENE-6590:
---

[~jpountz] this commit made this change:
{{
 @Override
-public void normalize(float queryNorm, float topLevelBoost) {
-  this.queryNorm = queryNorm * topLevelBoost;
-  queryWeight *= this.queryNorm;  // normalize query weight
+public void normalize(float queryNorm, float boost) {
+  this.boost = boost;
+  this.queryNorm = queryNorm;
+  queryWeight = queryNorm * boost * idf.getValue();
   value = queryWeight * idf.getValue(); // idf for document
 }
}}

Looking at this, before, the queryWeight was just the queryNorm* boost. Now, it 
is qeueryNorm* boost * IDF.

This means I'm seeing scores which instead of being TF * IDF are now TF * IDF * 
IDF.

Was this an intentional change?

> Explore different ways to apply boosts
> --
>
> Key: LUCENE-6590
> URL: https://issues.apache.org/jira/browse/LUCENE-6590
> Project: Lucene - Core
>  Issue Type: Wish
>Reporter: Adrien Grand
>Priority: Minor
> Fix For: 5.4
>
> Attachments: LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, 
> LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch, LUCENE-6590.patch
>
>
> Follow-up from LUCENE-6570: the fact that all queries are mutable in order to 
> allow for applying a boost raises issues since it makes queries bad cache 
> keys since their hashcode can change anytime. We could just document that 
> queries should never be modified after they have gone through IndexSearcher 
> but it would be even better if the API made queries impossible to mutate at 
> all.
> I think there are two main options:
>  - either replace "void setBoost(boost)" with something like "Query 
> withBoost(boost)" which would return a clone that has a different boost
>  - or move boost handling outside of Query, for instance we could have a 
> (immutable) query impl that would be dedicated to applying boosts, that 
> queries that need to change boosts at rewrite time (such as BooleanQuery) 
> would use as a wrapper.
> The latter idea is from Robert and I like it a lot given how often I either 
> introduced or found a bug which was due to the boost parameter being ignored. 
> Maybe there are other options, but I think this is worth exploring.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [DISCUSS] Lucene/Solr release management

[Upayavira]

My thoughts (from someone not prepared at the mo to do the work) -

How about creating a wizard? Asks you questions, "are you doing a
major/minor/bugfix release?", "What is the version number?" and have it
respond with commands that you must execute in a different window?

It seems to me that a lot of the confusion in the documentation is about
deciding which branch of the docs you should be following at any one
time, so the above could reduce that particular bit of complexity.

Upayavira

On Wed, 1 Jun 2016, at 07:11 PM, Steve Rowe wrote:
> 
> > On May 31, 2016, at 9:29 PM, Chris Hostetter <hossman_luc...@fucit.org> 
> > wrote:
> > 
> > if keeping track of what's already been done (and making it easier to make 
> > notes on problematic bits as they happen) then it seems like just cloning 
> > the "ReleaseTodo" page before the release, and adding a big  HERE 
> >  that moves down the page as the RM steps through things, and 
> > NOTE: ... to things above the HERE marker that had 
> > problems ... then when the release is done, folks can discuss/edit the 
> > original ReleaseTodo page based on the red notes.
> > 
> > If that sounds hackish to folks i would agree with them -- but it 
> > seems only slightly more hackish to me then tracking all of this in some 
> > other todo list tool, or a giant spreedsheet, and wouldn't require porting 
> > the existing docs into some other tool.
> 
> The main thing I was hoping to achieve was not requiring RMs to figure
> how to substitute the right stuff into the example commands themselves,
> but rather have some software do it for them.  The other stuff would be
> nice too, but are of lesser importance IMHO.  (In-situ notes would be
> helpful for remembering what needs fixing; and a checklist would be
> helpful for the interrupted RM: on some releases, some steps never got
> completed.)
> 
> I agree that copy/pasting from a display format into the command line is
> not all that helpful, but that’s already the current situation.
> 
> > My alternative straw man suggestion would be to make imcremental 
> > progress on simplifying the steps by writing small scripts to automated as 
> > many of the steps as possible, and merge those scripts when/where 
> > possible as we get more confident in them -- with the end goal being that 
> > ASF jenkins could run the whole thing with a few simple paramaterized jobs 
> > that are run on demand by RMs... the "create new major branch" job, 
> > the "create new minor branch" job, and the "create RC" job.
> 
> +1 to increase automation.  
> 
> Many of the current manual tasks are individually fairly simple, so
> scripting them (individually anyway) has seemed in the past to me like
> overkill.
> 
> I’m not sure we want Jenkins to do this stuff.
> 
> > I know i've suggested this before, and folks who have been RMs many times 
> > have told me it's a bad idea to trust automation for all of this -- but we 
> > should at least be able to automate *some* of it.  
> > 
> > Even if folks don't agree with the idea of letting scripts commit things 
> > or pushing RCs to the dist repo, there's still very little reason i can 
> > think of not to have scripts that *generate* & echo the exact commands 
> > based on the type of build so it's trivial for the RM to run them 
> > manually.
> 
> +1 to this step.  This is better than a spreadsheet (or similar)
> generating them, because inspection is still possible prior to running,
> and running is simpler (type in the script name vs. copy/paste a bunch of
> commands).
> 
> > if having a "checklist" is something RMs think would really be helpful -- 
> > why not at least automate the creation / processing of the checklist as 
> > much as possible with some simple scripts? 
> > 
> > Imagine having a simple JSON file in our repo listing all the steps and 
> > some metadata about when/why they matter, along with a 
> > release-checklist.py script...
> > 
> > release-checklist.py 6.1.0 RC0
> >  - makes a copy of the checklist JSON in some file that is .gitignore'd
> >  - updates the JSON to note that we're working on 6.1.0, RC0
> >  - deletes any stuff from the JSON that's only applicable for an X.0.0 
> >  - deletes any stuff that's only applicable when there are previous RCs
> > release-checklist.py next
> >  - echo's out the next thing the RM should do
> >  - or, when possible, runs a script for the next step, which should echo
> >out what it did and how to check/test the results
> >  - if the last item on the checklist isn't marked "don

Re: Lucene/Solr 6.0.1

[Upayavira]

There are a collection of minor UI patches languishing in JIRA that it
would be good to get out there too. I will endeavour to get them into
Git before Friday.

Upayavira

On Fri, 13 May 2016, at 06:07 PM, Steve Rowe wrote:
> Good idea, Adrien, but: I want to include SOLR-8992 in a 6.0.x release -
> it restores functionality unintentionally removed in 6.0.
> 
> --
> Steve
> www.lucidworks.com
> 
> > On May 13, 2016, at 12:53 PM, Adrien Grand <jpou...@gmail.com> wrote:
> > 
> > Hi Steve,
> > 
> > I think it is about time to do a 6.1 release as well since we have some 
> > nice pending improvements. So if that would cover your needs too, maybe we 
> > could skip 6.0.1 and do a 6.1 directly to save some work?
> > 
> > This is not an objection to doing a 6.0.1 release, I just wanted to throw 
> > out the idea of releasing 6.1 instead.
> > 
> > Le ven. 13 mai 2016 à 18:06, Steve Rowe <sar...@gmail.com> a écrit :
> > I’d like to make a 6.0.1 release, and I volunteer to be RM.
> > 
> > I propose to cut the first RC in one week: next Friday.
> > 
> > --
> > Steve
> > www.lucidworks.com
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9100) Add version-identifier to all files loaded by Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278738#comment-15278738
 ] 

Upayavira commented on SOLR-9100:
-

You will probably want to include the 'partials' files which are listed in 
solr/webapp/web/js/angular/app.js.

> Add version-identifier to all files loaded by Admin UI
> --
>
> Key: SOLR-9100
> URL: https://issues.apache.org/jira/browse/SOLR-9100
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 5.5, 6.0
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9100.patch
>
>
> The Angular UI added a bunch of javascript files to the base html, given that 
> we had some problems w/ users getting cached files in their Brower when using 
> a new release, i suggest we add those identifier (back) for those files as 
> well.
> [~upayavira] mind looking if i missed a reference?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9100) Add version-identifier to all files loaded by Admin UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15278595#comment-15278595
 ] 

Upayavira commented on SOLR-9100:
-

[~steffkes] absolutely no objection - go for it!

> Add version-identifier to all files loaded by Admin UI
> --
>
> Key: SOLR-9100
> URL: https://issues.apache.org/jira/browse/SOLR-9100
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 5.5, 6.0
>Reporter: Stefan Matheis (steffkes)
>Assignee: Stefan Matheis (steffkes)
>Priority: Minor
> Fix For: master (7.0)
>
> Attachments: SOLR-9100.patch
>
>
> The Angular UI added a bunch of javascript files to the base html, given that 
> we had some problems w/ users getting cached files in their Brower when using 
> a new release, i suggest we add those identifier (back) for those files as 
> well.
> [~upayavira] mind looking if i missed a reference?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-6688) There should be no error about a non-required file admin-extra.html

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-6688?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15277060#comment-15277060
 ] 

Upayavira commented on SOLR-6688:
-

The new admin UI, which is the default on 6.0+, does not implement the 
admin-extra functionality, for want of a good reason to implement it.

I agree with [~hossman_luc...@fucit.org] above, we should have a separate "we 
won't implement admin-extra" ticket, and mark this one as "not a problem for 
6.0+.

> There should be no error about a non-required file admin-extra.html
> ---
>
> Key: SOLR-6688
> URL: https://issues.apache.org/jira/browse/SOLR-6688
> Project: Solr
>  Issue Type: Bug
>Reporter: Arkadiusz Robiński
>Priority: Minor
>
> I am using SOLR 4.10.1. I have a simple configuration with 2 cores. Every 
> time I open the SOLR admin interface, I get the following errors:
> {noformat}
> Can not find: admin-extra.html
> Can not find: admin-extra.menu-top.html
> Can not find: admin-extra.menu-bottom.html
> {noformat}
> As far as I know, the files are optional. Therefore I should not get any 
> error, not even a warning.
> I do not want to create the files because I do not need them. The error 
> should simply not be there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8993) New UI can't show DIH

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15272236#comment-15272236
 ] 

Upayavira commented on SOLR-8993:
-

Please try the patch attached here. I never use DIH, so cannot really test it 
in earnest. If it works, I'll commit it and it can be a part of 6.0.1 or 6.1, 
which ever comes first.

> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: SOLR-8993.patch, screenshot-1.png, screenshot-2.png, 
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for 
> importing from database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9054) The new GUI is using hardcoded paths

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15266966#comment-15266966
 ] 

Upayavira commented on SOLR-9054:
-

Yes, it is a duplicate. 

When I implemented the new UI, I deliberately did NOT support diverting away 
from /solr. The location where Solr is mounted is not to be considered a 
user-configurable value - this, really, is a part of the move away from Solr 
being a War distributable to being an application in its own right.

Why do you want to replace the /solr portion of the URL?

> The new GUI is using hardcoded paths
> 
>
> Key: SOLR-9054
> URL: https://issues.apache.org/jira/browse/SOLR-9054
> Project: Solr
>  Issue Type: Bug
>  Components: web gui
>Affects Versions: 6.0
>Reporter: Valerio Di Cagno
>
> If Apache Solr 6.0 is started without using the default context root "/solr"
> every admin service will not work properly and is not possible to use the 
> provided links to go back to the old GUI.
> In the javascript files sometimes the parameter config.solr_path is ignored
> or replaced with the value /solr returning 404 on access.
> Affected files: 
> solr-webapp/webapp/js/services.js
> Suggested solution:
> Complete the integration with /js/scripts/app.js



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9032) Alias creation fails in new UI

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264285#comment-15264285
 ] 

Upayavira commented on SOLR-9032:
-

Thx for spotting, [~ctargett]

> Alias creation fails in new UI
> --
>
> Key: SOLR-9032
> URL: https://issues.apache.org/jira/browse/SOLR-9032
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>    Reporter: Upayavira
>Assignee: Upayavira
> Fix For: 6.0.1
>
> Attachments: SOLR-9032.patch
>
>
> Using the Collections UI to create an alias makes a call like this:
> http://$HOST:8983/solr/admin/collections?_=1461358635047=CREATEALIAS=%5Bobject+Object%5D=assets=json
> The collections param is effectively [object Object] which is clearly wrong, 
> and should be a comma separated list of collections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene/Solr 5.5.1

[Upayavira]

I would like to include at least one, possibly two, trivial but
significant fixes to the Solr Admin UI - SOLR-9032 is one of them, where
the create alias feature fails without telling you.
 
I'll try to get this committed by the end of the weekend.
 
Upayavira
 
On Fri, 29 Apr 2016, at 03:44 AM, Anshum Gupta wrote:
> I've updated the "Update Version Numbers in the Source Code" section
> on the ReleaseToDo page. It'd be good to have some one else also take
> a look at it.
>
> Here is what I've changed (only bug fix release):
> * Only bump up the version on the release branch using addVersion.py
> * Don't bump it up on the non-release versions in case of bug fix
>   release.
> * As part of the post-release process, use the commit hash from the
>   release branch version bump up, to increment the version on the non-
>   release branches.
>
> I thought we could do this for non bug-fix releases too, but I was
> wrong. Minor versions need to be bumped up on stable branches (and
> trunk) because during the release process for say version 6.1, there
> might be commits for 6.2 and we'd need stable branches and master,
> both to support those commits.
> We could debate about not needing something like this for major
> versions but then I don't think it's worth the pain of different
> release processes for each branch but I'm not stuck up with this.
>
>
> On Thu, Apr 28, 2016 at 5:31 PM, Anshum Gupta
> <ans...@anshumgupta.net> wrote:
>> That's fixed (about to commit the fix from LUCENE-7265) thought.
>>
>> While discussing the release process, Steve mentioned that we should
>> document the failing back-compat index test on the non-release
>> branches due to the missing index for the unreleased version.
>> On discussing further, he suggested that we instead move the process
>> of adding the version to non-release branches as a post-release task.
>> This way, we wouldn't have failing tests until the release goes
>> through and the back-compat indexes are checked in.
>>
>> We still would have failing tests for the release branch but there's
>> no way around that.
>>
>> So, I'll change the documentation to move those steps as post-
>> release tasks.
>>
>>
>> On Thu, Apr 28, 2016 at 11:40 AM, Anshum Gupta
>> <ans...@anshumgupta.net> wrote:
>>> Seems like LUCENE-6938 removed the merge logic that used the change
>>> id. Now the merge doesn't happen, and there's no logic that
>>> replaces it.
>>>
>>> I certainly can do with some help on this one.
>>>
>>> On Thu, Apr 28, 2016 at 11:24 AM, Anshum Gupta
>>> <ans...@anshumgupta.net> wrote:
>>>> Just wanted to make sure I wasn't missing something here again.
>>>> While trying to update the version on 5x, after having done that on
>>>> 5.5, using the addVersion.py script and following the instructions,
>>>> the command consistently fails. Here's what I've been trying to do:
>>>>
>>>> python3 -u dev-tools/scripts/addVersion.py --changeid 49ba147 5.5.1
>>>>
>>>> Seems like addVersion.py is broken for minor version releases so
>>>> I'd need some help with someone who has a better understanding of
>>>> python than I do. I observed that 5.5.1 Version gets added to
>>>> Version.java but also gets marked as deprecated.
>>>>
>>>>
>>>>
>>>> On Thu, Apr 28, 2016 at 9:27 AM, Anshum Gupta
>>>> <ans...@anshumgupta.net> wrote:
>>>>> Too much going on! Thanks Yonik.
>>>>> I'll start working on the RC now.
>>>>>
>>>>> NOTE: Please don't back port any more issues right now. In case of
>>>>>   exceptions, please raise them here.
>>>>>
>>>>> On Thu, Apr 28, 2016 at 9:09 AM, Yonik Seeley <ysee...@gmail.com>
>>>>> wrote:
>>>>>> On Thu, Apr 28, 2016 at 12:04 PM, Anshum Gupta
>>>>>> <ans...@anshumgupta.net> wrote:
>>>>>>  > Thanks. I'm waiting for the last back port of SOLR-8865.
>>>>>>
>>>>>> It should be already be there... I closed it yesterday.
>>>>>>
>>>>>> -Yonik
>>>>>>
>>>>>>  
>>>>>>  -
>>>>>>  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>>>  For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Anshum Gupta
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Anshum Gupta
>>>>
>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>>
>> --
>> Anshum Gupta
>>
>
>
>
> --
> Anshum Gupta
 

Re: How can we use an "OR" search between two fields

[Upayavira]

Yes. That will just work. Didn't you try it?
 
Upayavira
 
 
On Wed, 27 Apr 2016, at 01:24 PM, Mushthaq Rumy wrote:
> Hi,
> I just want to know whether is it possible to use "OR" search between
> two fields in Solr.
>
> Eg: field1:abc OR field2:abc
>
> Hoping for a kind response.
> Thanks & Regards,
>
>
>
> --
> Mushthaq Rumy
> *Software Engineer***
> Mobile : +94 (0) 779 492140[1]
> Email : musht...@wso2.com WSO2, Inc.; http://wso2.com/ lean .
> enterprise . middleware.
>
 

Links:

  1. tel:%2B94%20%280%29%20773%20451194

[jira] [Updated] (SOLR-9032) Alias creation fails in new UI

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira updated SOLR-9032:

Attachment: SOLR-9032.patch

The aliasCollections object is an array of objects, not strings. This patch 
correctly constructs a list of collection names when creating an alias.

> Alias creation fails in new UI
> --
>
> Key: SOLR-9032
> URL: https://issues.apache.org/jira/browse/SOLR-9032
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>    Reporter: Upayavira
>Assignee: Upayavira
> Fix For: 6.0.1
>
> Attachments: SOLR-9032.patch
>
>
> Using the Collections UI to create an alias makes a call like this:
> http://$HOST:8983/solr/admin/collections?_=1461358635047=CREATEALIAS=%5Bobject+Object%5D=assets=json
> The collections param is effectively [object Object] which is clearly wrong, 
> and should be a comma separated list of collections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9002) New Admin UI's File screen cannot display JSON files

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira updated SOLR-9002:

Attachment: SOLR-9002.patch

Another try

> New Admin UI's File screen cannot display JSON files
> 
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>    Assignee: Upayavira
> Attachments: SOLR-9002.patch, SOLR-9002.patch, SOLR-9002.patch, 
> SOLR-9002.patch, json file blank screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI 
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content 
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9002) New Admin UI's File screen cannot display JSON files

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira updated SOLR-9002:

Attachment: SOLR-9002.patch

Better now?

> New Admin UI's File screen cannot display JSON files
> 
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>    Assignee: Upayavira
> Attachments: SOLR-9002.patch, SOLR-9002.patch, SOLR-9002.patch, json 
> file blank screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI 
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content 
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9002) New Admin UI's File screen cannot display JSON files

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira updated SOLR-9002:

Attachment: SOLR-9002.patch

Patch that fixes JSON syntax highlighting

> New Admin UI's File screen cannot display JSON files
> 
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>    Assignee: Upayavira
> Attachments: SOLR-9002.patch, SOLR-9002.patch, json file blank 
> screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI 
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content 
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Created] (SOLR-9032) Alias creation fails in new UI

[Upayavira (JIRA)]

Upayavira created SOLR-9032:
---

 Summary: Alias creation fails in new UI
 Key: SOLR-9032
 URL: https://issues.apache.org/jira/browse/SOLR-9032
 Project: Solr
  Issue Type: Bug
  Components: UI
Affects Versions: 6.0
Reporter: Upayavira
Assignee: Upayavira
 Fix For: 6.0.1


Using the Collections UI to create an alias makes a call like this:

http://$HOST:8983/solr/admin/collections?_=1461358635047=CREATEALIAS=%5Bobject+Object%5D=assets=json

The collections param is effectively [object Object] which is clearly wrong, 
and should be a comma separated list of collections.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8715) New Admin UI's Schema screen fails for some fields

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15253556#comment-15253556
 ] 

Upayavira commented on SOLR-8715:
-

patch looks fine, but couldn't you just do: {code}if (!row.flags){code} rather 
than creating a new variable, rowFlags?

> New Admin UI's Schema screen fails for some fields
> --
>
> Key: SOLR-8715
> URL: https://issues.apache.org/jira/browse/SOLR-8715
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 5.5, 6.0
> Environment: mac, firefox
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
>  Labels: admin-interface
> Attachments: Problem shown in the released 5.5 version.png
>
>
> In techproducts example, using new Admin UI and trying to load the Schema for 
> text field causes blank screen and the Javascript error in the developer 
> console:
> {noformat}
> Error: row.flags is undefined
> getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:482:40
> $scope.refresh/http://localhost:8983/solr/js/angular/controllers/schema.js:76:38
> 
> {noformat}
> Tested with 5.5rc3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8918) Add Streaming Expressions to the admin page

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15249473#comment-15249473
 ] 

Upayavira commented on SOLR-8918:
-

You are right, globals suck. That's js not angular. You could add the 
subcontroller to the scope, that'd make it local.

> Add Streaming Expressions to the admin page
> ---
>
> Key: SOLR-8918
> URL: https://issues.apache.org/jira/browse/SOLR-8918
> Project: Solr
>  Issue Type: New Feature
>  Components: UI, web gui
>Reporter: Dennis Gove
> Attachments: SOLR-8918.patch, SOLR-8918.patch, SOLR-8918.patch, 
> SOLR-8918.patch, SOLR-8918.patch, sample-display.png, sample-display.png
>
>
> Add to the admin page an ability to work with and view Streaming Expressions.
> This tab will appear under the Collection selection section and will work 
> similarly to the Query tab. On this page the user will be able to enter a 
> streaming expression for execution. The user can then execute the expression 
> against the collection and view all the results as they are returned from the 
> Stream handler. Along with this the user will be able to view the structure 
> of the expression in a graph-like layout. 
> If the user wishes to only view the expression structure without executing 
> the expression the user will be able to click an "Explain" button which will 
> show the structure. Included in the structure will be information about each 
> node (the expression for that node).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8990) UI: query links from the "Top Terms" table on the Schema Browser page should use the "term" parser

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248313#comment-15248313
 ] 

Upayavira commented on SOLR-8990:
-

[~hossman_luc...@fucit.org] heck, you're getting good at this! :-) Patch looks 
good to me

> UI: query links from the "Top Terms" table on the Schema Browser page should 
> use the "term" parser
> --
>
> Key: SOLR-8990
> URL: https://issues.apache.org/jira/browse/SOLR-8990
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Reporter: Hoss Man
> Attachments: SOLR-8990.patch
>
>
> If you are using a StrField, or a TextField with a Keyword tokenizer then 
> it's very possible your indexed terms will include white space.
> But the links created  by the Schema Browser UI screen to serach for a term 
> in the "Top Terms" list assume that just prepending hte term with the 
> fieldname (ie: {{$fieldname + ":" $term}}) will be valid -- and instead they 
> don't match the correct term.
> 
> Example: 
> Load the {{example/films}} data into a "films" collection, and then load the 
> Schema Browser page for the "genre" field...
> http://127.0.1.1:8983/solr/#/films/schema?field=genre
> The "Top Terms" list includes terms such as {{Rommance Film}} but clicking on 
> this term takes you to this URL...
> http://127.0.1.1:8983/solr/#/films/query?q=genre:Romance%20Film
> ...which is just doing a search for "genre:Romance" OR "Film" (in the default 
> field)
> Instead it should link to...
> http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!term+f=genre%7DRomance+Film



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9010) Query tab - allow using browser "previous", "next" buttons to load previous/next queries in the form

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15248138#comment-15248138
 ] 

Upayavira commented on SOLR-9010:
-

[~jzak] yes, that's the idea

> Query tab - allow using browser "previous", "next" buttons to load 
> previous/next queries in the form
> 
>
> Key: SOLR-9010
> URL: https://issues.apache.org/jira/browse/SOLR-9010
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 5.5
> Environment: Lucene Solr for Linux (downloaded as an archive)
>Reporter: Jakub Zakrzewski
>
> Hi guys,
> I'm new here, however I have been using solr web admin interface for some 
> weeks now. 
> My problem is that I often would like to access my previous queries loaded in 
> the form. However it is not possible now.
> I'd like to have an url that opened will load the values to the form fields.
> Now the web gui displays an url which is a solr request url and not web admin 
> query url.
> I could implement this feature or create a web page that will use this 
> feature. Are you interested?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9010) Query tab - allow using browser "previous", "next" buttons to load previous/next queries in the form

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15247709#comment-15247709
 ] 

Upayavira commented on SOLR-9010:
-

I'm gonna assume for now that we're talking about the new UI (from Jan's 
index.html reference, he is too).

The issue if I recall it is that, in Angular, changing the URL triggers a 
reload of the controller. This changes the workflow of the page substantially - 
when executing a query, rather than building a Solr URL to pass to a service, 
you need to build an Angular URL, then, when the controller starts up again, 
parse that angular URL into the $scope, then build a Solr URL and execute it. 
Certainly not impossible, just a rather different way of doing it from how it 
was initially coded.

I'm certainly game for reviewing [~jzak]'s work if he wants to give it a go. 
I'd say, pretty much the entire work will be in js/angular/controllers/query.js.

> Query tab - allow using browser "previous", "next" buttons to load 
> previous/next queries in the form
> 
>
> Key: SOLR-9010
> URL: https://issues.apache.org/jira/browse/SOLR-9010
> Project: Solr
>  Issue Type: Improvement
>  Components: web gui
>Affects Versions: 5.5
> Environment: Lucene Solr for Linux (downloaded as an archive)
>Reporter: Jakub Zakrzewski
>
> Hi guys,
> I'm new here, however I have been using solr web admin interface for some 
> weeks now. 
> My problem is that I often would like to access my previous queries loaded in 
> the form. However it is not possible now.
> I'd like to have an url that opened will load the values to the form fields.
> Now the web gui displays an url which is a solr request url and not web admin 
> query url.
> I could implement this feature or create a web page that will use this 
> feature. Are you interested?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Scott Blum as a Lucene/Solr committer!

[Upayavira]

Welcome Scott!
 
 
On Tue, 19 Apr 2016, at 11:16 AM, David Smiley wrote:
> Welcome Scott!
>
> On Tue, Apr 19, 2016 at 9:21 AM Shalin Shekhar Mangar
>  wrote:
>> I'm pleased to announce that Scott Blum has accepted the Lucene PMC's
>> invitation to become a committer.
>>
>> Scott, it's tradition that you introduce yourself with a brief bio.
>>
>> Your handle "dragonsinth" has already added to the “lucene" LDAP
>> group, so you now have commit privileges. Please test this by adding
>> yourself to the committers section of the Who We Are page on the
>> website:  (use the ASF CMS
>> bookmarklet at the bottom of the page here:
>>  - more info here
>> ).
>>
>> The ASF dev page also has lots of useful links:
>> .
>>
>> Congratulations and welcome!
>>
>>
>> --
>> Regards,
>> Shalin Shekhar Mangar.
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com

[jira] [Assigned] (SOLR-9002) New Admin UI's File screen cannot display JSON files

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira reassigned SOLR-9002:
---

Assignee: Upayavira

> New Admin UI's File screen cannot display JSON files
> 
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>    Assignee: Upayavira
> Attachments: SOLR-9002.patch, json file blank screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI 
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content 
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-9002) New Admin UI's File screen cannot display JSON files

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira updated SOLR-9002:

Attachment: SOLR-9002.patch

AngularJS by default detects JSON and parses it. Thus, anything else 
(XML/HTML/text/etc) would come through as a string, but JSON would be parsed 
into Javascript objects, causing this error.

The attached patch prevents Angular's JSON parsing functionality, meaning JSON 
files are now displayed correctly in the Files tab.

> New Admin UI's File screen cannot display JSON files
> 
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
> Attachments: SOLR-9002.patch, json file blank screen.png
>
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI 
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content 
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-8715) New Admin UI's Schema screen fails for some fields

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira reassigned SOLR-8715:
---

Assignee: Upayavira

> New Admin UI's Schema screen fails for some fields
> --
>
> Key: SOLR-8715
> URL: https://issues.apache.org/jira/browse/SOLR-8715
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 5.5, 6.0
> Environment: mac, firefox
>Reporter: Alexandre Rafalovitch
>Assignee: Upayavira
>  Labels: admin-interface
> Fix For: 6.0
>
> Attachments: Problem shown in the released 5.5 version.png
>
>
> In techproducts example, using new Admin UI and trying to load the Schema for 
> text field causes blank screen and the Javascript error in the developer 
> console:
> {noformat}
> Error: row.flags is undefined
> getFieldProperties@http://localhost:8983/solr/js/angular/controllers/schema.js:482:40
> $scope.refresh/http://localhost:8983/solr/js/angular/controllers/schema.js:76:38
> 
> {noformat}
> Tested with 5.5rc3



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-8987) UI: Schema Browser doesn't show details for field names that start with underscore?

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira reassigned SOLR-8987:
---

Assignee: Upayavira

> UI: Schema Browser doesn't show details for field names that start with 
> underscore?
> ---
>
> Key: SOLR-8987
> URL: https://issues.apache.org/jira/browse/SOLR-8987
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Hoss Man
>Assignee: Upayavira
> Attachments: SOLR-8987.png
>
>
> * {{bin/solr -e cloud -noprompt}}
> * http://127.0.1.1:8983/solr/#/films/schema?field=_text_
> "Field Type:" and "Flags:" show nothing, and none of the analyzer info is 
> visible.
> work arround: use the old ui...
> http://127.0.1.1:8983/solr/old.html#/gettingstarted_shard1_replica2/schema-browser?field=_text_



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9002) New Admin UI's File screen cannot display JSON files

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15246762#comment-15246762
 ] 

Upayavira commented on SOLR-9002:
-

Where are you looking at the "params.json" file? I'm not aware of such a file 
in Solr. Which tab are you using that throws the error?

> New Admin UI's File screen cannot display JSON files
> 
>
> Key: SOLR-9002
> URL: https://issues.apache.org/jira/browse/SOLR-9002
> Project: Solr
>  Issue Type: Bug
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
>
> Default cloud example. Looking at the *params.json* file in the New Admin UI 
> shows empty screen and an Angular stack trace in the console.
> {noformat}
> "Error: [$sce:itype] Attempted to trust a non-string value in a content 
> requiring a string: Context: html
> http://errors.angularjs.org/1.3.8/$sce/itype?p0=html
> minErr/<@http://localhost:6001/solr/libs/angular.js:86:12
> trustAs@http://localhost:6001/solr/libs/angular.js:15167:1
> @http://localhost:6001/solr/libs/angular.js:15918:16
> $parseFilter@http://localhost:6001/solr/libs/angular.js:12168:14
> regularInterceptedExpression@http://localhost:6001/solr/libs/angular.js:12855:21
> expressionInputsWatch@http://localhost:6001/solr/libs/angular.js:12783:24
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14240:34
> $RootScopeProvider/this.$gethttp://localhost:6001/solr/libs/angular.js:14511:13
> timeout/timeoutId<@http://localhost:6001/solr/libs/angular.js:16237:25
> completeOutstandingRequest@http://localhost:6001/solr/libs/angular.js:4925:7
> Browser/self.defer/timeoutId<@http://localhost:6001/solr/libs/angular.js:5305:7
> "
> {noformat}
> The same functionality works in the old Admin UI.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-9000) New Admin UI hardcodes /solr context and fails when it changes

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-9000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15244161#comment-15244161
 ] 

Upayavira commented on SOLR-9000:
-

It is my impression that, since the switch to Solr being a standalone app, this 
prefix is not intended as  a user configurable thing. Therefore, no effort has 
gone into making it configuable within the admin UI.

> New Admin UI hardcodes /solr context and fails when it changes
> --
>
> Key: SOLR-9000
> URL: https://issues.apache.org/jira/browse/SOLR-9000
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Alexandre Rafalovitch
> Attachments: solr-wrong-urls-screenshot.png
>
>
> If the solr context is changed from */solr* to any other value (e.g. 
> */solr6_0/instance/solr1*), the new Admin UI does not work as it still tries 
> to load resources from */solr* prefix:
> The context is changed by editing server/contexts/solr-jetty-context.xml:
>  bq.  default="/solr6_0/instance/solr1"/>
> and by changing redirect in the server/etc/jetty.xml
> {quote}
> 
>   ^/$
>   /solr6_0/instance/solr1/
>  
> {quote}
> This affects New Admin UI, as well as both links between the UIs.
> The old Admin UI seems to work with the changed context, once it is manually 
> loaded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8993) New UI can't show DIH

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242958#comment-15242958
 ] 

Upayavira commented on SOLR-8993:
-

This patch is against trunk, but should work against other versions also. Apply 
it against the root of a Solr source checkout, then run 'ant server'. Once 
you've done that, you'll be able to use the normal bin/solr commands.

> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: SOLR-8993.patch, screenshot-1.png, screenshot-2.png, 
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for 
> importing from database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-8993) New UI can't show DIH

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira updated SOLR-8993:

Attachment: SOLR-8993.patch

Patch that:

 * fixes the dataimport service to use the correct URL for non /dataimport 
named handlers
 * doesn't set hasHandlers=false if the config isn't XML

> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: SOLR-8993.patch, screenshot-1.png, screenshot-2.png, 
> screenshot-3.png, screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for 
> importing from database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8993) New UI can't show DIH

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242909#comment-15242909
 ] 

Upayavira commented on SOLR-8993:
-

the underlying Angular service connects to /solr/$COLLECTION/dataimport, rather 
than /solr/$COLLECTION/$YOUR_DATAIMPORT_HANDLER. That's a bug.

Also, if it can't parse the XML, it fails, setting hasHandlers = false, showing 
the 'now handlers found' message. That's a bug also.

> New UI can't show DIH
> -
>
> Key: SOLR-8993
> URL: https://issues.apache.org/jira/browse/SOLR-8993
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Buğra Yıldırım
>Priority: Critical
> Attachments: screenshot-1.png, screenshot-2.png, screenshot-3.png, 
> screenshot-4.png, screenshot-5.png, screenshot-6.png
>
>
> New UI can't show DIHs when more than one DIH exists. I switch to old UI for 
> importing from database.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8956) Highlight missing in Analysis View

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242077#comment-15242077
 ] 

Upayavira commented on SOLR-8956:
-

[~steffkes] is it simply that if a term appears in both sides (query/index) it 
gets highlighted? Is this represented in the underlying data, or something you 
do client-side?

> Highlight missing in Analysis View
> --
>
> Key: SOLR-8956
> URL: https://issues.apache.org/jira/browse/SOLR-8956
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>Assignee: Upayavira
> Attachments: Solr+Admin+2016-04-06+12-03-36.png, 
> Solr+Admin+2016-04-06+12-09-23.png
>
>
> the new analysis view is missing the highlighting for matches. screenshots 
> appended to show the difference.
> this was reported by user {{mloeb}} on #solr yesterday. initially he asked 
> about highlighting in general - questioning a few things has gotten us to the 
> analysis view for debugging purposes. not seeing any highlights given the 
> index/query data - i've asked him to try the very same in the old admin ui 
> where it worked.
> i haven't dived in the code yet, probably [~upayavira] can give a hint where 
> / at what to look?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-8956) Highlight missing in Analysis View

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira reassigned SOLR-8956:
---

Assignee: Upayavira

> Highlight missing in Analysis View
> --
>
> Key: SOLR-8956
> URL: https://issues.apache.org/jira/browse/SOLR-8956
> Project: Solr
>  Issue Type: Bug
>  Components: Schema and Analysis, web gui
>Affects Versions: 5.4, 5.5, master
>Reporter: Stefan Matheis (steffkes)
>Assignee: Upayavira
> Attachments: Solr+Admin+2016-04-06+12-03-36.png, 
> Solr+Admin+2016-04-06+12-09-23.png
>
>
> the new analysis view is missing the highlighting for matches. screenshots 
> appended to show the difference.
> this was reported by user {{mloeb}} on #solr yesterday. initially he asked 
> about highlighting in general - questioning a few things has gotten us to the 
> analysis view for debugging purposes. not seeing any highlights given the 
> index/query data - i've asked him to try the very same in the old admin ui 
> where it worked.
> i haven't dived in the code yet, probably [~upayavira] can give a hint where 
> / at what to look?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Assigned] (SOLR-8991) UI: Ping option doesn't update menu with response time

[Upayavira (JIRA)]

 [ 
https://issues.apache.org/jira/browse/SOLR-8991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Upayavira reassigned SOLR-8991:
---

Assignee: Upayavira

> UI: Ping option doesn't update menu with response time
> --
>
> Key: SOLR-8991
> URL: https://issues.apache.org/jira/browse/SOLR-8991
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Hoss Man
>Assignee: Upayavira
>
> The ping menu option for a core doesn't provide any useful feedback to hte 
> user what it's doing (if anything).
> In the old UI it would display the #ms that the ping command took, but in the 
> new UI it seems to do the query i nthe background, but never indicate that it 
> succeeded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8991) UI: Ping option doesn't update menu with response time

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242052#comment-15242052
 ] 

Upayavira commented on SOLR-8991:
-

It had ng-show="pingMS", i.e. show the time if pingMS resolves to "true". If 
pingMS=0, it would resolve to false, and thus not show the time, which is 
wrong. I've fixed it so that whenever it does a ping, it will show the time 
regardless of what the numerical value is.

Does this resolve your issue?

> UI: Ping option doesn't update menu with response time
> --
>
> Key: SOLR-8991
> URL: https://issues.apache.org/jira/browse/SOLR-8991
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Hoss Man
>
> The ping menu option for a core doesn't provide any useful feedback to hte 
> user what it's doing (if anything).
> In the old UI it would display the #ms that the ping command took, but in the 
> new UI it seems to do the query i nthe background, but never indicate that it 
> succeeded.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8989) UI: Query screen can't handle query params that contain "=" (big problem trying to create link to pages that uses local params)

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15242022#comment-15242022
 ] 

Upayavira commented on SOLR-8989:
-

AngularJS is a bit more precise and thorough in what it expects when parsing a 
URL. The second equals isn't intended to be a URL component, rather a part of a 
parameter value. If you URL encode it (to a %3D), everything will work as you 
expect.


> UI: Query screen can't handle query params that contain "=" (big problem 
> trying to create link to pages that uses local params)
> ---
>
> Key: SOLR-8989
> URL: https://issues.apache.org/jira/browse/SOLR-8989
> Project: Solr
>  Issue Type: Bug
>Reporter: Hoss Man
>
> * {{bin/solr -e cloud -noprompt}}
> * http://127.0.1.1:8983/solr/#/gettingstarted/query
> * if you type either of these into the "q" param box, both queries works: 
> {noformat}
> {!lucene}foo
> {!lucene f=foo_s}foo
> {noformat}
> * if however you try to create a link to the UI page, only the first query 
> works, the second gets confused by the equal sign and ignores everything 
> after "f="
> ** http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!lucene%7Dfoo
> *** works
> ** 
> http://127.0.1.1:8983/solr/#/gettingstarted/query?q=%7B!lucene+f=foo_s%7Dfoo
> *** breaks



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8982) UI: Cloud -> Dump option isn't working

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15240297#comment-15240297
 ] 

Upayavira commented on SOLR-8982:
-

Or delete the functionality. What benefit does it give you? In what way is it 
useful to you?

> UI: Cloud -> Dump option isn't working
> --
>
> Key: SOLR-8982
> URL: https://issues.apache.org/jira/browse/SOLR-8982
> Project: Solr
>  Issue Type: Bug
>  Components: UI
>Affects Versions: 6.0
>Reporter: Hoss Man
>
> the "Dump" option on the (new) angular UI Cloud screen doesn't seem to be 
> working.  the "pre" tag where all the data is suppose to appear  is empty...
> http://127.0.1.1:8983/solr/#/~cloud
> Work around: use the older deprecated UI, it does appear to be working...
> http://127.0.1.1:8983/solr/old.html#/~cloud



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8918) Add Streaming Expressions to the admin page

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234990#comment-15234990
 ] 

Upayavira commented on SOLR-8918:
-

This is great! Will really help folks learn the streaming API.

Some questions:

Would it make sense to add two tabs at the top, one for streaming expressions, 
and the other for SQL?

The second suggestion is a lot more substantial. Given that the streaming API 
is essentially a programming language, would it be possible to add support for 
autocomplete or code suggestions to the editor?

There's a list of Javascript editors here, some of which support "code 
suggestions":
https://en.wikipedia.org/wiki/Comparison_of_JavaScript-based_source_code_editors

Thoughts?

> Add Streaming Expressions to the admin page
> ---
>
> Key: SOLR-8918
> URL: https://issues.apache.org/jira/browse/SOLR-8918
> Project: Solr
>  Issue Type: New Feature
>  Components: UI, web gui
>Reporter: Dennis Gove
> Attachments: SOLR-8918.patch, SOLR-8918.patch, sample-display.png
>
>
> Add to the admin page an ability to work with and view Streaming Expressions.
> This tab will appear under the Collection selection section and will work 
> similarly to the Query tab. On this page the user will be able to enter a 
> streaming expression for execution. The user can then execute the expression 
> against the collection and view all the results as they are returned from the 
> Stream handler. Along with this the user will be able to view the structure 
> of the expression in a graph-like layout. 
> If the user wishes to only view the expression structure without executing 
> the expression the user will be able to click an "Explain" button which will 
> show the structure. Included in the structure will be information about each 
> node (the expression for that node).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-8967) UI should not show the replication tab in the core selector panel in cloud mode

[Upayavira (JIRA)]

[ 
https://issues.apache.org/jira/browse/SOLR-8967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15234918#comment-15234918
 ] 

Upayavira commented on SOLR-8967:
-

Looks good to me

> UI should not show the replication tab in the core selector panel in cloud 
> mode
> ---
>
> Key: SOLR-8967
> URL: https://issues.apache.org/jira/browse/SOLR-8967
> Project: Solr
>  Issue Type: Improvement
>Reporter: Varun Thacker
> Attachments: SOLR-8967.patch
>
>
> When running Solr in cloud mode, the UI has a 'Replication' tab under 'Core 
> Selector' . 
> I think we should not display this when Solr is running in cloud mode. It 
> doesn't add any value as this is useful for master-slave setups. It could 
> also be harmful if someone accidentally clicks on 'Disable Replication' in 
> the UI. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org