[jira] [Resolved] (CASSANDRA-5974) Symlink Keys

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-5974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jonathan Ellis resolved CASSANDRA-5974.
---------------------------------------

    Resolution: Won't Fix

You could do this with triggers.  It's awfully specialized for us to add to core.

> Symlink Keys
> ------------
>
>                 Key: CASSANDRA-5974
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-5974
>             Project: Cassandra
>          Issue Type: New Feature
>            Reporter: Jason Fager
>            Priority: Minor
>
> Floated this on irc, was told to open a ticket here:
> We have a use case where a 3rd party sends us their id, we do a read to look up our internal id, and then turn around and do a write against that internal id.  We'd save a round trip if we could just do the write to our internal id via the external id; i.e., if we could treat the external id as a sort of symlink for our internal id.
> This use case doesn't seem like a great fit for secondary indexing, as there are potentially many external ids for each internal id, but only ever 1 internal id for each external id.  Another suggestion on irc was to use triggers; I haven't sat down to figure out if/how that would work, but I think the restriction against counter columns makes a trigger-based approach less than ideal.
> As a vague sketch of how I'd see this working, a symlink row would be distributed just like any other row, but would forward any operations on it to the real row.  If the symlink rowkey lands on a different node than the real rowkey, there's an extra network hop, but this is still an improvement over the current case (client > lookup_node > client -> real_node vs client -> symlink_node -> real_node).



--
This message was sent by Atlassian JIRA
(v6.1#6144)