tigerquoll commented on issue #577: SOLR-13260: 128 bit integer type - longlong
URL: https://github.com/apache/lucene-solr/pull/577#issuecomment-464960956
 
 
   Hi Toke, thanks for your comments. Its great to have someone with a bit more 
experience with the SOLR code base involved.  In answer to the question of why? 
 128 bit int are required to support a ipv6 field type 
(https://issues.apache.org/jira/browse/SOLR-6741).  I started off adding 
support for generic 128 bit field types as part of that jira, but ended up 
splitting it off into a separate commit as the basic type was more the capable 
of standing on its own, and somebody else may find the functionality useful.
   
   So if we want ipv6, we need a 128 bits.  I guess it is a valid question on 
whether we should expose a generic 128 bit type to anything else - I'm open to 
suggestions about what would be best here.
   
   In regards to supporting Solr functions - I agree - this is an area of 
significant concern for me as well.  Most (all?) field functions only support 
up to 64 bit types.  The tradeoff between implementation effort and end-user 
functionality for 128 bit point types is unlikely to be justifiable (and would 
likely involve performance tradeoffs).
   
   My concerns are primarily focussed on what is needed (and possibly useful) 
in supporting an ipv6 data type. If I can get away with doing something a count 
aggregation and nothing more I would call it a workable win.  Only exposing 
that functionality in the Ipv6 type make help to reduce end user confusion.
   
   
   

----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
[email protected]


With regards,
Apache Git Services

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to