[
https://issues.apache.org/jira/browse/CASSANDRA-19492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17906869#comment-17906869
]
Caleb Rackliffe commented on CASSANDRA-19492:
---------------------------------------------
[~dcapwell] started a thread on this a while back, "[DISCUSS] What SHOULD we do
when we index an inet type that is ipv4?"
I think where we settled there is that being consistent w/ normal filtering by
default w/ a per-index option to make ipv4 and ipv6 equivalent at query time
was the way forward. That would certainly be different than what we do right
now in the released 5.0.x versions. I have no problem with calling this a bug
fix, even if it being a bug is conditional on what the user actually wants and
whether the column is part of a primary key.
> Allow configurable v4/v6 address matching behavior for SAI indexes on CQL
> inet columns
> --------------------------------------------------------------------------------------
>
> Key: CASSANDRA-19492
> URL: https://issues.apache.org/jira/browse/CASSANDRA-19492
> Project: Apache Cassandra
> Issue Type: Improvement
> Components: Feature/SAI
> Reporter: Caleb Rackliffe
> Assignee: Ekaterina Dimitrova
> Priority: Normal
> Fix For: 5.0.x, 5.x
>
>
> The {{inet}} type in CQL allows ipv4 and ipv6 address formats to mix in the
> same column, and while there is a standard conversion between v4 and v6,
> equivalent addresses are not considered equal by Cassandra, when it comes to
> their usage in keys or in filtering queries. However, in SAI queries,
> equivalent v4 and v6 addresses ARE considered equal. Even if this behavior is
> useful, it might be a good idea to make the default behavior consistent with
> filtering, and allow the index configuration to control whether or not to
> consider them equal. (We have precedent for this w/ case-insensitive indexing
> of text columns, etc.)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
