Locking a key
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 362
- Forks
- 274
- Avg merge
- 4d 19m
- Merged PRs (30d)
- 12
Description
Hi,
I want to lock a key so that it cannot be edited in another transaction. I have looked at LockKeys() but looking at the implementation this doesn't seem to do what I want.
The only way I have been able to achieve this is by setting the value to what it already is and having it as part of the transaction. This means I have to read the value and then write it.
Something like below:
func TestLock(t *testing.T) {
client, err := txnkv.NewClient(context.TODO(), []string{"127.0.0.1:2379"}, config.Default())
require.NoError(t, err)
txn, err := client.Begin(context.TODO())
require.NoError(t, err)
txn1, err := client.Begin(context.TODO())
require.NoError(t, err)
require.NoError(t, txn1.Set([]byte("bar"), []byte{'0'}))
require.NoError(t, txn1.Commit(context.TODO()))
require.NoError(t, txn.Set([]byte("bar"), []byte{'0'}))
require.NoError(t, txn.Commit(context.TODO()))
}
Is there nothing I could do such as
func TestLock(t *testing.T) {
client, err := txnkv.NewClient(context.TODO(), []string{"127.0.0.1:2379"}, config.Default())
require.NoError(t, err)
txn, err := client.Begin(context.TODO())
require.NoError(t, err)
txn1, err := client.Begin(context.TODO())
require.NoError(t, err)
require.NoError(t, txn1.LockKeys([]byte("bar")))
require.NoError(t, txn1.Commit(context.TODO()))
require.NoError(t, txn.Set([]byte("bar"), []byte{'0'}))
require.NoError(t, txn.Commit(context.TODO()))
}
``` that would achieve the same?
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reading the LockKeys implementation and the transaction methods used in the examples, especially Set and Commit. Determine whether LockKeys is intended to provide the requested write-conflict behavior, then add a transaction test covering a lock-only transaction and a concurrent write; done means the test clearly verifies the desired outcome.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- databases
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 25/100