Solr
  1. Solr
  2. SOLR-4316

Admin UI - SolrCloud - extend core options to collections

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 4.1
    • Fix Version/s: 5.4, 6.0
    • Component/s: web gui
    • Labels:
      None

      Description

      There are a number of sections available when you are looking at a core in the UI - Ping, Query, Schema, Config, Replication, Analysis, Schema Browser, Plugins / Stats, and Dataimport are the ones that I can see.

      A list of collections should be available, with as many of those options that can apply to a collection, If options specific to collections/SolrCloud can be implemented, those should be there too.

      1. collection-overview-panel.png
        113 kB
        Upayavira
      2. collections menu open.png
        50 kB
        Upayavira
      3. cores menu open.png
        71 kB
        Upayavira
      4. schema-browser.png
        66 kB
        Upayavira
      5. SOLR-4316.patch
        41 kB
        Upayavira
      6. SOLR-4316.patch
        29 kB
        Upayavira
      7. SOLR-4316.patch
        144 kB
        Shalin Shekhar Mangar
      8. solrcloud-admin-ui-menu.png
        65 kB
        Shalin Shekhar Mangar
      9. two-selectors.png
        64 kB
        Upayavira

        Issue Links

          Activity

          Hide
          Shawn Heisey added a comment -

          If you have SolrCloud enabled, IMHO the list should have collapsible sections for collections and cores, with collections open and cores collapsed.

          Show
          Shawn Heisey added a comment - If you have SolrCloud enabled, IMHO the list should have collapsible sections for collections and cores, with collections open and cores collapsed.
          Hide
          Shawn Heisey added a comment -

          If this is significant work, perhaps we can start with the Query interface on this issue and open new issues for other functionality.

          Show
          Shawn Heisey added a comment - If this is significant work, perhaps we can start with the Query interface on this issue and open new issues for other functionality.
          Hide
          Shawn Heisey added a comment -

          Clarification on why I filed this issue:

          If SolrCloud is enabled and you have a distributed index, you can currently open up the admin interface and send queries to one core. You can't send them to an entire collection. From what I was told when helping someone on IRC, it sounds like Solr 4.0.0 used the collection name as the core name, so perhaps 4.0.0 could do this, but 4.1 has collection_shardN_replicaN for the core name.

          While I was thinking about this, I looked at the other things you can do on a core and figured that most of them might be useful on a collection. While it is a good idea to implement as much functionality as possible, perhaps this one issue should be about queries.

          Show
          Shawn Heisey added a comment - Clarification on why I filed this issue: If SolrCloud is enabled and you have a distributed index, you can currently open up the admin interface and send queries to one core. You can't send them to an entire collection. From what I was told when helping someone on IRC, it sounds like Solr 4.0.0 used the collection name as the core name, so perhaps 4.0.0 could do this, but 4.1 has collection_shardN_replicaN for the core name. While I was thinking about this, I looked at the other things you can do on a core and figured that most of them might be useful on a collection. While it is a good idea to implement as much functionality as possible, perhaps this one issue should be about queries.
          Hide
          Mark Miller added a comment -

          If SolrCloud is enabled and you have a distributed index, you can currently open up the admin interface and send queries to one core. You can't send them to an entire collection.

          That's not right. You query the whole collection unless you pass the param distrib=false.

          Show
          Mark Miller added a comment - If SolrCloud is enabled and you have a distributed index, you can currently open up the admin interface and send queries to one core. You can't send them to an entire collection. That's not right. You query the whole collection unless you pass the param distrib=false.
          Hide
          Shawn Heisey added a comment -

          That's not right. You query the whole collection unless you pass the param distrib=false.

          Very interesting! That's not what I would have expected ... which IMHO violates the principle of least surprise. If the core has the same name as the collection, then it's not a violation of that principle, and from what I understand, a 4.0.0 install does name the cores the same as the collection. I have not actually used 4.0.0 myself.

          If cores are going to continue with the 4.1 method of having distinct names from the collection, then I think a request to a core should not go cloud-wide unless you specifically request that with an option.

          Users who have never touched Solr before using SolrCloud of course have no expectations about how things work, and probably will appreciate this behavior. It would be a similar situation for experienced users that have never tried the shards parameter.

          Users like me that have distributed experience with older versions would be very surprised by this behavior, and will be looking for a "collections" section in the admin UI – which is exactly what happened when I first started working with SolrCloud.

          Show
          Shawn Heisey added a comment - That's not right. You query the whole collection unless you pass the param distrib=false. Very interesting! That's not what I would have expected ... which IMHO violates the principle of least surprise. If the core has the same name as the collection, then it's not a violation of that principle, and from what I understand, a 4.0.0 install does name the cores the same as the collection. I have not actually used 4.0.0 myself. If cores are going to continue with the 4.1 method of having distinct names from the collection, then I think a request to a core should not go cloud-wide unless you specifically request that with an option. Users who have never touched Solr before using SolrCloud of course have no expectations about how things work, and probably will appreciate this behavior. It would be a similar situation for experienced users that have never tried the shards parameter. Users like me that have distributed experience with older versions would be very surprised by this behavior, and will be looking for a "collections" section in the admin UI – which is exactly what happened when I first started working with SolrCloud.
          Hide
          Mark Miller added a comment -

          It's how most distributed systems work. You hit one node, it queries your cluster by default - not just that one node.

          Show
          Mark Miller added a comment - It's how most distributed systems work. You hit one node, it queries your cluster by default - not just that one node.
          Hide
          Shawn Heisey added a comment -

          If you decide that the current request-to-shard behavior is preferable to changing things, then I think that the query UI needs a highly visible notice that requests to that shard will actually go to the entire collection unless they make distrib=false, and there needs to be a checkbox for that parameter.

          Either way, I think it's a good idea to make collections available as entities within the UI.

          Show
          Shawn Heisey added a comment - If you decide that the current request-to-shard behavior is preferable to changing things, then I think that the query UI needs a highly visible notice that requests to that shard will actually go to the entire collection unless they make distrib=false, and there needs to be a checkbox for that parameter. Either way, I think it's a good idea to make collections available as entities within the UI.
          Hide
          Mark Miller added a comment -

          a checkbox for that parameter.

          I think it would be cool if someone added that.

          I think it's a good idea to make collections available as entities within the UI.

          I think the right first step is to add a UI for the collections API - similar to the one for the CoreAdmin API.

          For UI stuff though, I've been depending on the kindness of one stranger mostly

          Show
          Mark Miller added a comment - a checkbox for that parameter. I think it would be cool if someone added that. I think it's a good idea to make collections available as entities within the UI. I think the right first step is to add a UI for the collections API - similar to the one for the CoreAdmin API. For UI stuff though, I've been depending on the kindness of one stranger mostly
          Hide
          Shawn Heisey added a comment -

          As Mark Miller says, getting the collections API into the GUI is a first step. The number one thing I would like to see is interactive CREATE functionality. The number two thing I'd like to see is DELETE functionality, with the right amount of "are you sure you want to do this?" prompting.

          This comment is part of an effort to close old issues that I have reported. Search tag: elyograg2013springclean

          Show
          Shawn Heisey added a comment - As Mark Miller says, getting the collections API into the GUI is a first step. The number one thing I would like to see is interactive CREATE functionality. The number two thing I'd like to see is DELETE functionality, with the right amount of "are you sure you want to do this?" prompting. This comment is part of an effort to close old issues that I have reported. Search tag: elyograg2013springclean
          Hide
          Shawn Heisey added a comment -

          I should have put that comment on SOLR-4388. That has been done.

          Show
          Shawn Heisey added a comment - I should have put that comment on SOLR-4388 . That has been done.
          Hide
          Steve Rowe added a comment -

          Bulk move 4.4 issues to 4.5 and 5.0

          Show
          Steve Rowe added a comment - Bulk move 4.4 issues to 4.5 and 5.0
          Hide
          Uwe Schindler added a comment -

          Move issue to Solr 4.9.

          Show
          Uwe Schindler added a comment - Move issue to Solr 4.9.
          Hide
          Shalin Shekhar Mangar added a comment -

          I am going to put up a patch shortly which will:

          1. Refactor the UI into core specific and collection specific features,
          2. Provide a drop down for available collections and local cores
          3. Add a simple collection overview page
          Show
          Shalin Shekhar Mangar added a comment - I am going to put up a patch shortly which will: Refactor the UI into core specific and collection specific features, Provide a drop down for available collections and local cores Add a simple collection overview page
          Hide
          Shalin Shekhar Mangar added a comment -

          Here's how the new menu looks like in SolrCloud. In non-solrcloud installations, the admin menu would look the same as it does today.

          Show
          Shalin Shekhar Mangar added a comment - Here's how the new menu looks like in SolrCloud. In non-solrcloud installations, the admin menu would look the same as it does today.
          Hide
          Mark Miller added a comment -

          Sweet! Long overdue change.

          Show
          Mark Miller added a comment - Sweet! Long overdue change.
          Hide
          Shawn Heisey added a comment -

          The UI looks pretty good. I have one concern. Because I nearly always have a hi-res display, this won't really affect me, but I thought it worthwhile to mention:

          Users of low-res displays might appreciate having one dropdown with both collections and cores, similar to what we have on the schema browser for Fields, DynamicFields, and Types. This would be particularly important when we make the UI compatible with mobile browsers – SOLR-4794.

          Show
          Shawn Heisey added a comment - The UI looks pretty good. I have one concern. Because I nearly always have a hi-res display, this won't really affect me, but I thought it worthwhile to mention: Users of low-res displays might appreciate having one dropdown with both collections and cores, similar to what we have on the schema browser for Fields, DynamicFields, and Types. This would be particularly important when we make the UI compatible with mobile browsers – SOLR-4794 .
          Hide
          Shalin Shekhar Mangar added a comment -

          Users of low-res displays might appreciate having one dropdown with both collections and cores, similar to what we have on the schema browser for Fields, DynamicFields, and Types.

          I know Shawn but right now you can have a collection and a core named the same e.g. "collection1". How would you choose one over the other? I think, eventually, we want to move away from the local core concept in the UI and navigate to individual cores from a collection view but I want to take small baby steps right now.

          That reminds me that the current menu has a fixed height I guess because on lower resolutions, one cannot scroll to the bottom of the menu. Instead, part of the menu is just cut off below the viewport and becomes unreachable. This is something that we should fix anyways. This is especially a problem during workshop/demos because the projectors have low resolution.

          Show
          Shalin Shekhar Mangar added a comment - Users of low-res displays might appreciate having one dropdown with both collections and cores, similar to what we have on the schema browser for Fields, DynamicFields, and Types. I know Shawn but right now you can have a collection and a core named the same e.g. "collection1". How would you choose one over the other? I think, eventually, we want to move away from the local core concept in the UI and navigate to individual cores from a collection view but I want to take small baby steps right now. That reminds me that the current menu has a fixed height I guess because on lower resolutions, one cannot scroll to the bottom of the menu. Instead, part of the menu is just cut off below the viewport and becomes unreachable. This is something that we should fix anyways. This is especially a problem during workshop/demos because the projectors have low resolution.
          Hide
          Shalin Shekhar Mangar added a comment -

          This patch adds a collection drop down and segregates collection specific views from core specific views.

          The path to core specific views is changed to #/~core/core_name/ and the path used earlier for these views e.g. #/collection1/ is now used for collection specific views.

          The menu is unchanged if Solr is not running in cloud mode.

          The collection dashboard shows basic collection stats such as replicationFactor, maxShardsPerNode, total number of nodes and document counts (overall and per-shard). This is not even close to finished yet because as you can see after you apply the patch, the dashboard page still shows remnants from my copy/paste of core dashboard.

          I need to work on SOLR-6325 before I can finish this dashboard.

          In the meanwhile, if anyone has ideas on how to present/visualize this information, please feel free to leave a comment with your ideas.

          Show
          Shalin Shekhar Mangar added a comment - This patch adds a collection drop down and segregates collection specific views from core specific views. The path to core specific views is changed to #/~core/core_name/ and the path used earlier for these views e.g. #/collection1/ is now used for collection specific views. The menu is unchanged if Solr is not running in cloud mode. The collection dashboard shows basic collection stats such as replicationFactor, maxShardsPerNode, total number of nodes and document counts (overall and per-shard). This is not even close to finished yet because as you can see after you apply the patch, the dashboard page still shows remnants from my copy/paste of core dashboard. I need to work on SOLR-6325 before I can finish this dashboard. In the meanwhile, if anyone has ideas on how to present/visualize this information, please feel free to leave a comment with your ideas.
          Hide
          Shalin Shekhar Mangar added a comment -

          Stefan Matheis (steffkes) suggested that we combine the two selection boxes for collection and local cores into one but group them together just as how the Analysis page shows a single selection box with field names and field types.

          I have gone back and forth on this. It isn't hard to implement because it takes just a "optgroup" html element to group both types together. But after a lot of thought I am leaning towards keeping these two separate because:

          1. Imagine "collection1" which is both a collection as well as a core name. Once the user has already selected one of them there is no way to indicate what has been selected (except the fact that different options show depending on what's selected)
          2. The Analysis page shows field types and names together but they're also functionally equivalent with respect to that page. However, different functions apply on collections and cores.

          The cons of having two selection boxes is that it takes more screen space and we turn on scrolling only when the viewport size is smaller (or it is resized to be smaller).

          Show
          Shalin Shekhar Mangar added a comment - Stefan Matheis (steffkes) suggested that we combine the two selection boxes for collection and local cores into one but group them together just as how the Analysis page shows a single selection box with field names and field types. I have gone back and forth on this. It isn't hard to implement because it takes just a "optgroup" html element to group both types together. But after a lot of thought I am leaning towards keeping these two separate because: Imagine "collection1" which is both a collection as well as a core name. Once the user has already selected one of them there is no way to indicate what has been selected (except the fact that different options show depending on what's selected) The Analysis page shows field types and names together but they're also functionally equivalent with respect to that page. However, different functions apply on collections and cores. The cons of having two selection boxes is that it takes more screen space and we turn on scrolling only when the viewport size is smaller (or it is resized to be smaller).
          Hide
          Mark Miller added a comment -

          Imagine "collection1" which is both a collection as well as a core name

          At some point, we just need to make this illegal.

          I could go either way on the selection boxes I think. Keep leaning towards keeping them separate too.

          Show
          Mark Miller added a comment - Imagine "collection1" which is both a collection as well as a core name At some point, we just need to make this illegal. I could go either way on the selection boxes I think. Keep leaning towards keeping them separate too.
          Hide
          Shawn Heisey added a comment -

          At some point, we just need to make this illegal.

          I like this idea. It's probably best to do it in 5.0, even though I'd really want it in released code yesterday! Having cores and collections named the same causes confusion.

          Show
          Shawn Heisey added a comment - At some point, we just need to make this illegal. I like this idea. It's probably best to do it in 5.0, even though I'd really want it in released code yesterday! Having cores and collections named the same causes confusion.
          Hide
          Stefan Matheis (steffkes) added a comment -

          1. Imagine "collection1" which is both a collection as well as a core name. Once the user has already selected one of them there is no way to indicate what has been selected (except the fact that different options show depending on what's selected)

          That's right, we already have the problem, that there is no place on the screen where you can see the complete core-/collection-name (in case it gets truncated because it's to long for the dropdown ..)

          One idea a coworker had: Add another line (mentioning 'core' or 'collection', depending on the choice) on top of the current label. we would have to extend the library we use (chosen) to make that happen, because right now it is prepared to show one line (which is by default the label of the selected option from the dropdown).

          in case the name is something thoughtfully selected (like collection1 ;>) that would look a little bit odd, since it would say

          collection
          collection1

          but i guess, that would be acceptable?

          Show
          Stefan Matheis (steffkes) added a comment - 1. Imagine "collection1" which is both a collection as well as a core name. Once the user has already selected one of them there is no way to indicate what has been selected (except the fact that different options show depending on what's selected) That's right, we already have the problem, that there is no place on the screen where you can see the complete core-/collection-name (in case it gets truncated because it's to long for the dropdown ..) One idea a coworker had: Add another line (mentioning 'core' or 'collection', depending on the choice) on top of the current label. we would have to extend the library we use (chosen) to make that happen, because right now it is prepared to show one line (which is by default the label of the selected option from the dropdown). in case the name is something thoughtfully selected (like collection1 ;>) that would look a little bit odd, since it would say collection collection1 but i guess, that would be acceptable?
          Hide
          Upayavira added a comment -

          I started playing with this yesterday. I started mocking up Shalin's patch in Angular. The patch as he showed it in the screenshot is pretty easy - two dropdowns, and submenus below those dropdowns.

          The issue I stumbled upon was actually URL structure rather than the dropdowns.

          We have:
          http://localhost:8983/solr/#/~xyz for a page 'xyz' that is not core specific.
          http://localhost:8983/solr/#/core1/tab1 for a page that is specific to a particular core.

          How do we represent, in a URL, a link to a page that is specific to a particular collection?

          Do we need something like:

          http://localhost:8983/solr/#/@collection1/tab1 (using some marker (e.g. @) to signify a collection

          Or do we just say that, for example:

          http://localhost:8983/solr/#/assets/analysis <-- is a collection page, because analysis is collection specific
          http://localhost:8983/solr/#/assets/segments <-- is a core page, because segment info is core specific

          Thoughts?

          Show
          Upayavira added a comment - I started playing with this yesterday. I started mocking up Shalin's patch in Angular. The patch as he showed it in the screenshot is pretty easy - two dropdowns, and submenus below those dropdowns. The issue I stumbled upon was actually URL structure rather than the dropdowns. We have: http://localhost:8983/solr/#/~xyz for a page 'xyz' that is not core specific. http://localhost:8983/solr/#/core1/tab1 for a page that is specific to a particular core. How do we represent, in a URL, a link to a page that is specific to a particular collection? Do we need something like: http://localhost:8983/solr/#/@collection1/tab1 (using some marker (e.g. @) to signify a collection Or do we just say that, for example: http://localhost:8983/solr/#/assets/analysis <-- is a collection page, because analysis is collection specific http://localhost:8983/solr/#/assets/segments <-- is a core page, because segment info is core specific Thoughts?
          Hide
          Upayavira added a comment -

          I'm inclined to use the latter approach. Let each page decide whether the thing after the #/ is a core name or a collection name. We do that already in standard Solr URLs.

          Either we let each page decide, if the page only works with cores or with collections, or we check for a collection first, and if we don't find one, we fall back to a core.

          The schema browser really is the only tab we have at the moment that is ambiguous - the schema is shared across a collection, but the term info is core specific. In my first pass I'll make it core specific. Later we could have it on both, with a flag telling us which, and if you click "show term info" on the collections page, it'll give you a list of replicas to try it on.

          Show
          Upayavira added a comment - I'm inclined to use the latter approach. Let each page decide whether the thing after the #/ is a core name or a collection name. We do that already in standard Solr URLs. Either we let each page decide, if the page only works with cores or with collections, or we check for a collection first, and if we don't find one, we fall back to a core. The schema browser really is the only tab we have at the moment that is ambiguous - the schema is shared across a collection, but the term info is core specific. In my first pass I'll make it core specific. Later we could have it on both, with a flag telling us which, and if you click "show term info" on the collections page, it'll give you a list of replicas to try it on.
          Hide
          Upayavira added a comment -

          Patch that separates out collection specific tabs from core specific tabs, when in cloud mode

          Show
          Upayavira added a comment - Patch that separates out collection specific tabs from core specific tabs, when in cloud mode
          Hide
          Shalin Shekhar Mangar added a comment -

          The schema browser really is the only tab we have at the moment that is ambiguous - the schema is shared across a collection, but the term info is core specific

          Right but schema really only belongs in a cloud tab. The term info is index specific. Perhaps we can rename the existing Segment Info page to "Index Info" and add the Field Selector + Term Info in there?

          Show
          Shalin Shekhar Mangar added a comment - The schema browser really is the only tab we have at the moment that is ambiguous - the schema is shared across a collection, but the term info is core specific Right but schema really only belongs in a cloud tab. The term info is index specific. Perhaps we can rename the existing Segment Info page to "Index Info" and add the Field Selector + Term Info in there?
          Hide
          Upayavira added a comment -

          I've mulled on this quite a bit. What you say makes a huge amount of sense - a collection focused "schema" tab and a core focused "index" tab.

          However, that's a reasonable amount of work, and I'd rather get this feature out before I engage with creating two very new panes, and all the issues of interlinking them.

          How's about, in the meantime, when in cloud mode, I add an annotation close to the "load terms" button saying "terms will be loaded from the XYZ core and do not represent the whole collection".

          Would that work? Then, if people are happy with that, I can complete this task and get on with working on the collections API tab in SOLR-4388.

          Show
          Upayavira added a comment - I've mulled on this quite a bit. What you say makes a huge amount of sense - a collection focused "schema" tab and a core focused "index" tab. However, that's a reasonable amount of work, and I'd rather get this feature out before I engage with creating two very new panes, and all the issues of interlinking them. How's about, in the meantime, when in cloud mode, I add an annotation close to the "load terms" button saying "terms will be loaded from the XYZ core and do not represent the whole collection". Would that work? Then, if people are happy with that, I can complete this task and get on with working on the collections API tab in SOLR-4388 .
          Hide
          Erick Erickson added a comment -

          bq: Would that work? Then, if people are happy with that, I can complete this task and get on with working on the collections

          Let's do the minimum necessary to cut over to the new Angular JS version. I think it's important to get people using that version, flush out any lingering issues then move on with improvements rather than wait for new functionality.

          FWIW

          Show
          Erick Erickson added a comment - bq: Would that work? Then, if people are happy with that, I can complete this task and get on with working on the collections Let's do the minimum necessary to cut over to the new Angular JS version. I think it's important to get people using that version, flush out any lingering issues then move on with improvements rather than wait for new functionality. FWIW
          Hide
          Upayavira added a comment -

          My take is ever so slightly different - I'd like to do the absolute minimum to make it worth people's time to switch over to the new one.

          To my mind, that is this ticket and SOLR-4388. If we have both of these in place as new features, and have covered SOLR-7856 then I'd be happy to proceed to make it default. Still aiming for all that for 5.4.

          i.e. if we're gonna make things worse for people (some lingering bugs) we might as well also make it a little better (new features).

          Show
          Upayavira added a comment - My take is ever so slightly different - I'd like to do the absolute minimum to make it worth people's time to switch over to the new one. To my mind, that is this ticket and SOLR-4388 . If we have both of these in place as new features, and have covered SOLR-7856 then I'd be happy to proceed to make it default. Still aiming for all that for 5.4. i.e. if we're gonna make things worse for people (some lingering bugs) we might as well also make it a little better (new features).
          Hide
          Shalin Shekhar Mangar added a comment -

          However, that's a reasonable amount of work, and I'd rather get this feature out before I engage with creating two very new panes, and all the issues of interlinking them.
          How's about, in the meantime, when in cloud mode, I add an annotation close to the "load terms" button saying "terms will be loaded from the XYZ core and do not represent the whole collection".

          Sounds good to me. The reason why I was never able to complete this issue was because it required me to create a completely new page (Collection Dashboard) so let's shoot for progress first and perfection after.

          Show
          Shalin Shekhar Mangar added a comment - However, that's a reasonable amount of work, and I'd rather get this feature out before I engage with creating two very new panes, and all the issues of interlinking them. How's about, in the meantime, when in cloud mode, I add an annotation close to the "load terms" button saying "terms will be loaded from the XYZ core and do not represent the whole collection". Sounds good to me. The reason why I was never able to complete this issue was because it required me to create a completely new page (Collection Dashboard) so let's shoot for progress first and perfection after.
          Hide
          Upayavira added a comment -

          Shalin Shekhar Mangar you challenged me. I agree with the need for a collection dashboard (I'd already noted it in a comment in the code). So, I have knocked one together, and attached a screenshot and patch to this ticket. It shows just what is available via the collections API CLUSTERSTATUS option, with open/closable shards and replicas. The "Core" link under a replica should be clickable, too.

          Show
          Upayavira added a comment - Shalin Shekhar Mangar you challenged me. I agree with the need for a collection dashboard (I'd already noted it in a comment in the code). So, I have knocked one together, and attached a screenshot and patch to this ticket. It shows just what is available via the collections API CLUSTERSTATUS option, with open/closable shards and replicas. The "Core" link under a replica should be clickable, too.
          Hide
          Shalin Shekhar Mangar added a comment -

          Upayavira - thanks! Looks good and we can always add more in time! +1

          Show
          Shalin Shekhar Mangar added a comment - Upayavira - thanks! Looks good and we can always add more in time! +1
          Hide
          Upayavira added a comment -

          On the schema browser page, I've opted for a simple message (see schema-browser.png screenshot) saying "N.B. Loaded from a single core - not from the whole collection."

          This is, IMO, good enough to consider this ticket complete.

          Show
          Upayavira added a comment - On the schema browser page, I've opted for a simple message (see schema-browser.png screenshot) saying "N.B. Loaded from a single core - not from the whole collection." This is, IMO, good enough to consider this ticket complete.
          Hide
          Upayavira added a comment -

          I will commit this in the next day or two, unless anyone objects.

          Show
          Upayavira added a comment - I will commit this in the next day or two, unless anyone objects.
          Hide
          ASF subversion and git services added a comment -

          Commit 1698459 from Upayavira in branch 'dev/trunk'
          [ https://svn.apache.org/r1698459 ]

          SOLR-4316 add a collections dropdown alongside cores dropdown

          Show
          ASF subversion and git services added a comment - Commit 1698459 from Upayavira in branch 'dev/trunk' [ https://svn.apache.org/r1698459 ] SOLR-4316 add a collections dropdown alongside cores dropdown
          Hide
          ASF subversion and git services added a comment -

          Commit 1698460 from Upayavira in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1698460 ]

          SOLR-4316 add a collections dropdown alongside cores dropdown

          Show
          ASF subversion and git services added a comment - Commit 1698460 from Upayavira in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1698460 ] SOLR-4316 add a collections dropdown alongside cores dropdown
          Hide
          ASF subversion and git services added a comment -

          Commit 1700064 from shalin@apache.org in branch 'dev/trunk'
          [ https://svn.apache.org/r1700064 ]

          SOLR-4316: Fix precommit failures

          Show
          ASF subversion and git services added a comment - Commit 1700064 from shalin@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1700064 ] SOLR-4316 : Fix precommit failures
          Hide
          ASF subversion and git services added a comment -

          Commit 1700065 from shalin@apache.org in branch 'dev/branches/branch_5x'
          [ https://svn.apache.org/r1700065 ]

          SOLR-4316: Fix precommit failures

          Show
          ASF subversion and git services added a comment - Commit 1700065 from shalin@apache.org in branch 'dev/branches/branch_5x' [ https://svn.apache.org/r1700065 ] SOLR-4316 : Fix precommit failures

            People

            • Assignee:
              Upayavira
              Reporter:
              Shawn Heisey
            • Votes:
              0 Vote for this issue
              Watchers:
              8 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development