[jira] [Comment Edited] (SOLR-5017) Allow sharding based on the value of a field

2013-07-10 Thread Yonik Seeley (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13704536#comment-13704536
 ] 

Yonik Seeley edited comment on SOLR-5017 at 7/10/13 1:17 PM:
-

bq. What if I to have a clean 'id' value which is devoid of extra information? 
Should I do id.substring(id.indexOf(!) everytime I use it elsewhere ?

Why would you have to do that?  If ! appears in the ID field by accident 
sometimes, everything still works as expected with the compositeId router - 
that's why it's the default.

edit: Oh, I think I see what you mean... you want to use the id unchanged as a 
foreign key. You could always store that as a separate field too.  Anyway, I'm 
not arguing against using another field, but I do think it's the less common 
and more complex solution (given that you now need to provide that extra value 
everywhere).

  was (Author: ysee...@gmail.com):
bq. What if I to have a clean 'id' value which is devoid of extra 
information? Should I do id.substring(id.indexOf(!) everytime I use it 
elsewhere ?

Why would you have to do that?  If ! appears in the ID field by accident 
sometimes, everything still works as expected with the compositeId router - 
that's why it's the default.
  
 Allow sharding based on the value of a field
 

 Key: SOLR-5017
 URL: https://issues.apache.org/jira/browse/SOLR-5017
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul

 We should be able to create a collection where sharding is done based on the 
 value of a given field
 collections can be created with shardField=fieldName, which will be persisted 
 in DocCollection in ZK
 implicit DocRouter would look at this field instead of _shard_ field
 CompositeIdDocRouter can also use this field instead of looking at the id 
 field. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Comment Edited] (SOLR-5017) Allow sharding based on the value of a field

2013-07-09 Thread Noble Paul (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13703039#comment-13703039
 ] 

Noble Paul edited comment on SOLR-5017 at 7/9/13 8:11 AM:
--

bq.I could see by default, the compositeId router also paying attention to the 
\_shard_ parameter

the \_shard_ parameter is the actual name of the shard. In case of compositeId 
router , the client is agnostic of the shard name and all that it cares about 
is shard.keys. What I mean to say is, the name \_shard_ can be a bit confusing

As of now we don't have a plan on how to do shard splitting for 'implicit' 
router. Let's keep it as  TBD

In case of compositeId router , I would like to read the part before the (!) to 
be read from the 'shardField'. The semantics will be exactly same as it is now. 
Reading the value from a request parameter would mean we will need to persist 
it along with the document in some field . 

  was (Author: noble.paul):
bq.I could see by default, the compositeId router also paying attention to 
the _shard_ parameter

the _shard_ parameter is the actual name of the shard. In case of compositeId 
router , the client is agnostic of the shard name and all that it cares about 
is shard.keys. What I mean to say is, the name _shard_ can be a bit confusing

As of now we don't have a plan on how to do shard splitting for 'implicit' 
router. Let's keep it as  TBD

In case of compositeId router , I would like to read the part before the (!) to 
be read from the 'shardField'. The semantics will be exactly same as it is now. 
Reading the value from a request parameter would mean we will need to persist 
it along with the document in some field . 
  
 Allow sharding based on the value of a field
 

 Key: SOLR-5017
 URL: https://issues.apache.org/jira/browse/SOLR-5017
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul

 We should be able to create a collection where sharding is done based on the 
 value of a given field
 collections can be created with shardField=fieldName, which will be persisted 
 in DocCollection in ZK
 implicit DocRouter would look at this field instead of _shard_ field
 CompositeIdDocRouter can also use this field instead of looking at the id 
 field. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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



[jira] [Comment Edited] (SOLR-5017) Allow sharding based on the value of a field

2013-07-09 Thread Noble Paul (JIRA)

[ 
https://issues.apache.org/jira/browse/SOLR-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13703039#comment-13703039
 ] 

Noble Paul edited comment on SOLR-5017 at 7/9/13 10:49 AM:
---

bq.I could see by default, the compositeId router also paying attention to the 
\_shard_ parameter

the \_shard_ parameter is the actual name of the shard. In case of compositeId 
router , the client is agnostic of the shard name and all that it cares about 
is shard.keys. What I mean to say is, the name \_shard_ can be a bit confusing

As of now we don't have a plan on how to do shard splitting for 'implicit' 
router. Let's keep it as  TBD

In case of compositeId router , I would like to read the part before the \(!) 
to be read from the 'shardField'. The semantics will be exactly same as it is 
now. Reading the value from a request parameter would mean we will need to 
persist it along with the document in some field . 

  was (Author: noble.paul):
bq.I could see by default, the compositeId router also paying attention to 
the \_shard_ parameter

the \_shard_ parameter is the actual name of the shard. In case of compositeId 
router , the client is agnostic of the shard name and all that it cares about 
is shard.keys. What I mean to say is, the name \_shard_ can be a bit confusing

As of now we don't have a plan on how to do shard splitting for 'implicit' 
router. Let's keep it as  TBD

In case of compositeId router , I would like to read the part before the (!) to 
be read from the 'shardField'. The semantics will be exactly same as it is now. 
Reading the value from a request parameter would mean we will need to persist 
it along with the document in some field . 
  
 Allow sharding based on the value of a field
 

 Key: SOLR-5017
 URL: https://issues.apache.org/jira/browse/SOLR-5017
 Project: Solr
  Issue Type: Sub-task
Reporter: Noble Paul
Assignee: Noble Paul

 We should be able to create a collection where sharding is done based on the 
 value of a given field
 collections can be created with shardField=fieldName, which will be persisted 
 in DocCollection in ZK
 implicit DocRouter would look at this field instead of _shard_ field
 CompositeIdDocRouter can also use this field instead of looking at the id 
 field. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

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