Feature request: command COPY

[GoogleCodeExporter]

Command COPY for all types of keys which copy a key

Original issue reported on code.google.com by ivanshum...@gmail.com on 27 Dec 2010 at 1:15

[GoogleCodeExporter]

Second for this - use case:  scored set that represents a super-class (e.g. 
middle east) may be good initial copy of class, e.g. Libya

Original comment by dr.marc....@gmail.com on 6 Apr 2011 at 1:53

[GoogleCodeExporter]

Set and scored sets already have two names for each of these: 
sunionstore/sinterstore and zunionstore/zinterstore. With a single input 
set/zset, all of them copy the input set/zset.

Strings, lists, and hashes don't have a built-in copy, however.

Original comment by josiah.c...@gmail.com on 6 Apr 2011 at 5:24

[GoogleCodeExporter]

would be so handy for debugging, could diagnose problems without popping data 
out of the original list, stuff like that, really useful.

Original comment by sentimen...@gmail.com on 4 May 2012 at 3:49

[GoogleCodeExporter]

Redis 2.6 now has DUMP and RESTORE, which can be used to copy. Recommended 
close this issue as being solved.

Original comment by josiah.c...@gmail.com on 8 May 2012 at 4:02

[GoogleCodeExporter]

Recommend, not close. DUMP and RESTORE have completely different semantics and 
require an external tool (at a minimum a screen session) to copy the value of 
one key to another. This request is for an atomic COPY command which is 
completely different in every way.

Original comment by sentimen...@gmail.com on 8 May 2012 at 4:23

[GoogleCodeExporter]

You can create your own atomic copy command in Redis 2.6 with the EVAL command.

script = '''
local data = redis.call('DUMP', keys[1]); 
return redis.call('RESTORE', keys[2], data)
'''
EVAL "local data = redis.call('dump', KEYS[1]); return redis.call('restore', 
keys[2], data)" 2 source dest

Recommended close.

Original comment by josiah.c...@gmail.com on 8 May 2012 at 4:47

[GoogleCodeExporter]

That command could just as easily been named EVIL rather than EVAL. Embedding a 
Lua interpreter? Why Dear Lord, why? Anyhow all that stuff is a world away from:

SET cat "mr snoofles"
COPY cat cat_bak
SET cat "mr tiddles"
GET cat_bak

Mark the bug as 'wont fix; if you wish to close it. It is remarkably obtuse to 
consider your suggestion a fix for the original request.

Imagine if you will, if GNU/Linux was missing the 'cp' command, would a 
adequate work around be to write a C program that copied the data byte by byte 
from source to dest? 

Yeah, and before you say it, I do know the dd command, in the biblical sense of 
the word.... 

Original comment by irishj...@gmail.com on 8 May 2012 at 5:13

[GoogleCodeExporter]

Historically Redis has had the perspective that if you can implement a new 
feature with existing commands having identical semantics, that you don't 
implement the new feature. I don't know the base reasoning that Salvatore uses, 
but I agree with the reality (and have had my requested features rejected 
because of it).

From a learning/documentation perspective, Redis has over 100 commands. You may 
think "hey, it's just 1 more command". But that command must be written, 
documented, and maintained. Not adding commands is arguably a better long-term 
strategy than adding commands.

You are also entitled to your opinion about Lua, but that opinion will do 
nothing to dissuade Salvatore from keeping Lua (especially because many other 
people like the idea, and are using it). Refusing to use Lua when it offered as 
a solution because it is "ugly", despite it offering the desired/needed 
semantics, will likely get you nowhere.

Original comment by josiah.c...@gmail.com on 8 May 2012 at 6:42

[GoogleCodeExporter]

It's not that it's ugly. 

It's that it's a lot easier to reason a command, even for a non-programmer - 
than to learn yet another scripting language and implement it that way. 

The reason people have asked for this feature is mainly for use in debugging 
scenarios. 

I want a snapshot of this value, be it a list or whatever, leave the original 
as it is.

Right now, I'm only commenting on this issue because it seems like such a 
glaring omission, and like something which would be trivial to implement, or 
perhaps not, and with enormous usefulness. 

I haven't built a business on the existence of the copy command or have any 
vested interest in it's existence or lack thereof. 

It makes no huge difference to me if the command exists or not, as a 
programmer, I can create a script or program that does the same thing, it just 
seems silly that it doesn't exist.

Original comment by sentimen...@gmail.com on 8 May 2012 at 6:49

[GoogleCodeExporter]

Instead, if it exists, it will get misused in all the possible ways, like it 
happened for KEYS.
COPY would be an O(N) command, possibly slow. If the user is smart enough to 
write a two lines script maybe he has good reasons for using it, but I don't 
think COPY is a legitimate command otherwise, given the philosophy of Redis of 
not including commands that can't solve problems at scale when it is not 
strictly needed semantically.

Instead what we should get is a non-deleting version of MIGRATE, to perform a 
copy of the key into another instance. This would help and it is planned.

Original comment by anti...@gmail.com on 9 May 2012 at 8:23

[GoogleCodeExporter]

Dude, I noticed you ported Redis to Windows. 

Wasn't that hazardous, given the competency of that user-base? Perhaps you 
should blue screen their machines to protect them from themselves? 

Saying the user is too stupid to understand the cost of the COPY command is at 
best disingenuous and at worst, condescending and borderline insulting.

And besides, there are plenty of constructs which don't scale well (if 
misused), LRANGE being just one of them.

Original comment by sentimen...@gmail.com on 9 May 2012 at 10:12

[GoogleCodeExporter]

please pick one: arrogant or clueless, but don't show both the attitude here.

1) I never ported Redis to windows. Check your facts.
2) It does not matter in this discussion.
3) LRANGE complexity clearly states shows, if you understand big-O, that 
getting latest elements from one of the side of the list is fast, and anyway, 
you need a way to fetch data from a list. While you don't need COPY.
4) Picking the right orthogonal primitives is the work of the designer, it's 
not something that is true or wrong, it's a matter of taste, but you have to 
accept it, or fork Redis.
5) I did not say that users are stupid, but if a primitive is there, even if 
inherently inefficient and semantically not required for the intended use of 
the software, it's like saying that to copy keys is an ok operation, which is 
not.

Now stop blabbing here please, we have work to do and don't need flames nor 
that way of conducting discussions here. Closing the issue.

Original comment by anti...@gmail.com on 9 May 2012 at 10:35

• Changed state: WontFix

[GoogleCodeExporter]

    Owner   redisdb-win32   Redis DB Win32 port

Original comment by sentimen...@gmail.com on 9 May 2012 at 10:41

[GoogleCodeExporter]

From http://redis.io/download: "The Redis project does not directly support 
win32/win64..."

There are links to Windows ports on that page. One port appears to be a 
Microsoft initiative: http://bit.ly/KbrxIO

Original comment by mk...@yahoo.com on 9 May 2012 at 10:07

[GoogleCodeExporter]

If you looked at the list of changes in the redisdb-win32 port, you would 
discover that it has had 1 change since its creation 3 years ago, which 
includes 0 lines in 0 source files. The one downloadable file was uploaded 3 
years ago by the other owner of the project, and has since been left to rot.

Your evidence claiming that Salvatore is in any way directly working on a 
Windows port is lacking.

Original comment by josiah.c...@gmail.com on 10 May 2012 at 1:15

[GoogleCodeExporter]

Josiah, Look here old chap, I'm not saying you guys are actively working on a 
windows port. I came here to comment on the fact that your team doesn't want to 
support the 'COPY' command, apparently because it's better to implement it 
using lua in an 'EVAL' block... somehow based on the rationale of protecting 
the retarded from themselves... because in OS, the user never knows best. 

My retort was that he was involved in redisdb-win32, in fact he is listed as 
the project owner.

Now, if you really want to raise the level of your user-base, supporting a 
Cygwin port, with all it's attendant horror seems to be counterintuitive. 

All this noise, good lord! And the cognitive dissonance is deafening!

Original comment by sentimen...@gmail.com on 10 May 2012 at 9:19

[GoogleCodeExporter]

1. Operating system choice is unrelated to the proposed COPY feature. You 
brought user operating system choice into the mix, not anyone actually involved 
with Redis.
2. If by "involved" you mean "added as an owner by the other owner some 3+ 
years ago and having contributed nothing", then I suppose you are right. Me, 
I'll go with the interpretation of everyone but you: Salvatore didn't port 
Redis to Windows, contrary to your earlier claim "Dude, I noticed you ported 
Redis to Windows."
3. Salvatore is not supporting a cygwin port, as can be seen by the fact that 
he hasn't done anything in the project over the course of 3 years, and the fact 
that it isn't even linked from the redis.io download page: 
http://redis.io/download (despite including 2 other links to unofficial windows 
ports)
4. The other owner on that project, arguably, is also not supporting the port, 
as Redis has received on the order of 100k lines of code since April of 2009, 
none of which has been merged, compiled, or uploaded to that project.

Your claim of cognitive dissonance would be more convincing if you kept to 
speaking about the topic: whether COPY should be included. Instead, you 
repeatedly bring up unrelated topics, resort to ad-hominem attacks, and then 
claim that others can't see their own contrary thinking.

In particular, you said, "It makes no huge difference to me if the command 
exists or not, as a programmer, I can create a script or program that does the 
same thing, it just seems silly that it doesn't exist." If this was your 
legitimate perspective, you wouldn't be arguing about it.

/unfollow

Original comment by josiah.c...@gmail.com on 11 May 2012 at 12:00

[GoogleCodeExporter]

Eep, this conversation went sour quickly!

I would like to +1 this feature. :) I think it would be pretty nice to have.

Original comment by marc.pn....@gmail.com on 4 Jun 2014 at 11:32

[GoogleCodeExporter]

The issue was closed over 2 years ago, and this bug tracker is no longer active.

If you want to open a new issue that will (very likely be immediately closed), 
you are free to visit the new bug tracker at Github: 
https://github.com/antirez/redis/issues .

Original comment by josiah.c...@gmail.com on 5 Jun 2014 at 12:01