Hi,
It has been a long time since the Woodstox jars have been updated. Is
this intentional, as in are there any issues if we use the latest jars
with Solr?
Thanks,
Kumar
The current way of allowing the omission of a core name in the URL is
to name the core DEFAULT_CORE.
While this functionality is great, and allows a multi-core setup to be
back compat with existing URLs, if someone does want to also refer to
the core by it's proper name, it looks pretty ugly.
Yonik Seeley wrote:
The current way of allowing the omission of a core name in the URL is
to name the core DEFAULT_CORE.
While this functionality is great, and allows a multi-core setup to be
back compat with existing URLs, if someone does want to also refer to
the core by it's proper name,
On Thu, Jan 14, 2010 at 12:22 PM, Mark Miller markrmil...@gmail.com wrote:
I think we should do both - allow marking any core as the default and
change our single core example solr.xml to use collection1 rather than
DEFAULT_CORE.
+1
-Yonik
http://www.lucidimagination.com
Logical shard sounds good as the collection of all identical physical
shards
Another concept from Katta that is AFAIK missing from the Solr lexicon is
the distinction between node and shard. In Katta, a node is a server worker
instance that contains and queries physical shards. There is usually
I'm actually starting to lean toward slice instead of logical shard.
In the future we'll want to enable overlapping shards I think (due to
an Amazon Dynamo type of replication, or due to merging shards, etc),
and a separate word for a logical slice of the index seems desirable.
For instance, one
On Thu, Jan 14, 2010 at 12:30 PM, Ted Dunning ted.dunn...@gmail.com wrote:
Another concept from Katta that is AFAIK missing from the Solr lexicon is
the distinction between node and shard. In Katta, a node is a server worker
instance that contains and queries physical shards.
I think it's
On Thu, Jan 14, 2010 at 12:46 PM, Yonik Seeley
yo...@lucidimagination.com wrote:
I'm actually starting to lean toward slice instead of logical shard.
I've gone with this for now and updated http://wiki.apache.org/solr/SolrCloud
but it's certainly not written in stone if people want to try and
I think that most of these complications go away to a remarkable degree if
you combine katta style random assignment of small shards.
The major simplifications there include:
- no need to move individual documents, nor to split or merge shards, no
need for search-server to search-server
: The current way of allowing the omission of a core name in the URL is
: to name the core DEFAULT_CORE.
...
: 1) allow an optional flag in solr.xml to mark that any core is also
: the default core
: 2) rename DEFAULT_CORE to something nicer like collection1
...having a default=true
Chris Hostetter wrote:
: The current way of allowing the omission of a core name in the URL is
: to name the core DEFAULT_CORE.
...
: 1) allow an optional flag in solr.xml to mark that any core is also
: the default core
: 2) rename DEFAULT_CORE to something nicer like collection1
: parameter we use for this. Suggestions? logicalshards=shard1,shard2?
: lshards=shard1,shard2? slice=shard1,shard2? It doesn't seem like it
: would be easy to reuse the shards parameter for this since it refers
: to physical shard addresses.
I haven't been following the SolrCloud stuff much,
Allowing changing the special default core name, and as a default default
core name, switch to using collection1 rather than DEFAULT_CORE
---
[
https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-1722:
--
Attachment: SOLR-1722.patch
Quick patch whipped off to show the idea.
Allowing changing the special
[
https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800311#action_12800311
]
Yonik Seeley commented on SOLR-1722:
I never really looked at the previous
[
https://issues.apache.org/jira/browse/SOLR-1722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800318#action_12800318
]
Mark Miller commented on SOLR-1722:
---
I'll have to check it out a little more - Noble
On Thu, Jan 14, 2010 at 1:58 PM, Chris Hostetter
hossman_luc...@fucit.org wrote:
: parameter we use for this. Suggestions? logicalshards=shard1,shard2?
: lshards=shard1,shard2? slice=shard1,shard2? It doesn't seem like it
: would be easy to reuse the shards parameter for this since it refers
I saw some previous threads related to this subject, but on a slightly
different use case, so staring a new thread...
For reference, a related thread topic can be found here:
http://www.lucidimagination.com/search/document/2025d6670004838b/date_faceting_and_double_counting#2025d6670004838b
I have found that users of the system like to use index as the composite of
all nodes/shards/slices that is searched in response to a query. It is the
ultimate logical entity. Really, this is the same abstraction that users
of Lucene have. They really don't want to care that a Lucene index is
But I've kind of gotten used to thinking of shards as the
actual physical queryable things...
I think a mistake was made referring to Solr cores as shards.
It's the same thing with 2 different names. Slices adds yet
another name which seems to imply the same thing yet again. I'd
rather see
Although Jason has some valid points here, I'm with Yonik here. I do
believe that we've gotten used to the terms core to represent a single
index and shard to be represented by a single core. A node seems to
indicate a machine or a JVM. Changing any of these (informal perhaps)
definitions will
Uri,
core to represent a single index and shard to be
represented by a single core
Can you elaborate on what you mean, isn't a core a single index
too? It seems like shard was used to represent a remote index
(perhaps?). Though here I'd prefer remote core, because to the
uninitiated Solr
Shard has the interesting additional implication that it is part of a
composite index made up of many sub-indexes.
A lucene index could be a complete index or a shard. I would presume the
same of what might be called a core.
On Thu, Jan 14, 2010 at 3:21 PM, Jason Rutherglen
Yonik spake-
I'm actually starting to lean toward slice instead of logical shard.
In the future we'll want to enable overlapping shards I think (due to
an Amazon Dynamo type of replication, or due to merging shards, etc),v
and a separate word for a logical slice of the index seems
[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800471#action_12800471
]
Hoss Man commented on SOLR-1677:
bq. And I also can't see anyone really spending time to
My definition of right is simple and modularized with minimal conceptual
upheaval.
As such, simply giving SOLR a good shard manager that broadcasts queries
without respect to content is a preferable solution than something very
fancy.
On Thu, Jan 14, 2010 at 4:31 PM, Lance Norskog
[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800484#action_12800484
]
Marvin Humphrey commented on SOLR-1677:
---
I'd still like to clarify this whole issue
[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800514#action_12800514
]
Hoss Man commented on SOLR-1677:
{quote}
Yes. The whole point is to avoid Analyzer
[
https://issues.apache.org/jira/browse/SOLR-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12800518#action_12800518
]
Robert Muir commented on SOLR-1677:
---
bq. The implication i got from Robert was that there
29 matches
Mail list logo
