Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unique constraint on an index should throw an error if an item already exists #7

Open
slackpad opened this issue Dec 2, 2015 · 4 comments

Comments

@slackpad
Copy link
Contributor

slackpad commented Dec 2, 2015

This came up in hashicorp/consul#1463 where I found I could create multiple entries by name, even though there's a unique constraint on that index.

MemDB should throw an error if an item is being inserted into an index marked unique, and there's an existing item there, and that item's primary key doesn't match the incoming one.

@jmheidly
Copy link

I wonder why nobody has given this issue a thought. It is much needed fix as it defies the purpose of the unique property.

@armon
Copy link
Member

armon commented Jan 4, 2017

@jmheidly Mostly because our apps that use it (Consul, Nomad) avoid this issue in higher level application code.

@zouqiang8233
Copy link

I found a problem. If the index uses the int type, not wrong, but can not query the results through the index.

@hbagdi
Copy link
Contributor

hbagdi commented Oct 28, 2018

#49 could solve this.

hackerwins added a commit to yorkie-team/yorkie that referenced this issue May 18, 2022
There is an issue that the same records are inserted even if the
unique field is specified in go-memdb. And the maintainer guides avoiding
this in the application.

hashicorp/go-memdb#7 (comment)
hackerwins added a commit to yorkie-team/yorkie that referenced this issue May 18, 2022
There is an issue that the same records are inserted even if the
unique field is specified in go-memdb. And the maintainer guides avoiding
this in the application.

hashicorp/go-memdb#7 (comment)
hackerwins added a commit to yorkie-team/yorkie that referenced this issue May 18, 2022
There is an issue that the same records are inserted even if the
unique field is specified in go-memdb. And the maintainer guides avoiding
this in the application.

hashicorp/go-memdb#7 (comment)
hackerwins added a commit to yorkie-team/yorkie that referenced this issue May 18, 2022
There is an issue that the same records are inserted even if the
unique field is specified in go-memdb. And the maintainer guides avoiding
this in the application.

hashicorp/go-memdb#7 (comment)
hackerwins added a commit to yorkie-team/yorkie that referenced this issue May 18, 2022
There is an issue that the same records are inserted even if the
unique field is specified in go-memdb. And the maintainer guides avoiding
this in the application.

hashicorp/go-memdb#7 (comment)
jeonjonghyeok pushed a commit to jeonjonghyeok/yorkie that referenced this issue Aug 4, 2022
…eam#329)

There is an issue that the same records are inserted even if the
unique field is specified in go-memdb. And the maintainer guides avoiding
this in the application.

hashicorp/go-memdb#7 (comment)
absolutelightning added a commit that referenced this issue May 24, 2024
* Remove releng from CODEOWNERS

* Bump github.com/hashicorp/go-immutable-radix from 1.3.0 to 1.3.1 (#134)

Bumps [github.com/hashicorp/go-immutable-radix](https://github.com/hashicorp/go-immutable-radix) from 1.3.0 to 1.3.1.
- [Release notes](https://github.com/hashicorp/go-immutable-radix/releases)
- [Changelog](https://github.com/hashicorp/go-immutable-radix/blob/master/CHANGELOG.md)
- [Commits](hashicorp/go-immutable-radix@v1.3.0...v1.3.1)

---
updated-dependencies:
- dependency-name: github.com/hashicorp/go-immutable-radix
  dependency-type: direct:production
  update-type: version-update:semver-patch
...

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>

* version bump

* fix module

---------

Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: Alvin Huang <17609145+alvin-huang@users.noreply.github.com>
Co-authored-by: Michele Degges <mdeggies@gmail.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants