You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Furthermore, I kind of expect "id" like fields to be first in the definition of a type.
Similar situation for Organization.name too.
Here are some things that we could do to improve the situation for both User and Organization (not mutually exclusive, could to some or all of them).
Move the uniqueness documentation to the `name` field on `User` and `CreateUsersRequest.Value`
diff --git a/buf/registry/owner/v1beta1/user.proto b/buf/registry/owner/v1beta1/user.proto
index 366b31e..77c444a 100644
--- a/buf/registry/owner/v1beta1/user.proto+++ b/buf/registry/owner/v1beta1/user.proto@@ -21,8 +21,6 @@ import "buf/validate/validate.proto";
import "google/protobuf/timestamp.proto";
// A user on the BSR.
-//-// A name uniquely identifies a User, however name is mutable.
message User {
option (buf.registry.priv.extension.v1beta1.message).response_only = true;
@@ -36,6 +34,7 @@ message User {
// The last time the User was updated.
google.protobuf.Timestamp update_time = 3 [(buf.validate.field).required = true];
// The name of the User.
+ // A name uniquely identifies a User, however name is mutable.
string name = 4 [
(buf.validate.field).required = true,
(buf.validate.field).string.max_len = 255
diff --git a/buf/registry/owner/v1beta1/user_service.proto b/buf/registry/owner/v1beta1/user_service.proto
index 969f28f..a964ab1 100644
--- a/buf/registry/owner/v1beta1/user_service.proto+++ b/buf/registry/owner/v1beta1/user_service.proto@@ -83,6 +83,7 @@ message CreateUsersRequest {
// An individual request to create a User.
message Value {
// The name of the User.
+ // A name uniquely identifies a User, however name is mutable.
string name = 1 [
(buf.validate.field).required = true,
(buf.validate.field).string.max_len = 255
Move `name` to be field 2 so it is next to `id`
diff --git a/buf/registry/owner/v1beta1/user.proto b/buf/registry/owner/v1beta1/user.proto
index 366b31e..1402edf 100644
--- a/buf/registry/owner/v1beta1/user.proto+++ b/buf/registry/owner/v1beta1/user.proto@@ -21,8 +21,6 @@ import "buf/validate/validate.proto";
import "google/protobuf/timestamp.proto";
// A user on the BSR.
-//-// A name uniquely identifies a User, however name is mutable.
message User {
option (buf.registry.priv.extension.v1beta1.message).response_only = true;
@@ -31,15 +29,16 @@ message User {
(buf.validate.field).required = true,
(buf.validate.field).string.uuid = true
];
- // The time the User was created.- google.protobuf.Timestamp create_time = 2 [(buf.validate.field).required = true];- // The last time the User was updated.- google.protobuf.Timestamp update_time = 3 [(buf.validate.field).required = true];
// The name of the User.
- string name = 4 [+ // A name uniquely identifies a User, however name is mutable.+ string name = 2 [
(buf.validate.field).required = true,
(buf.validate.field).string.max_len = 255
];
+ // The time the User was created.+ google.protobuf.Timestamp create_time = 3 [(buf.validate.field).required = true];+ // The last time the User was updated.+ google.protobuf.Timestamp update_time = 4 [(buf.validate.field).required = true];
// The type of the User.
UserType type = 5 [
(buf.validate.field).required = true,
Consider naming the field `username` or `handle` instead of `name`
Especially for a User which is like a person, it isn't natural to think of someone's name as being unique.
handle is potentially better because it works for organizations too (username would be a more awkward on an Organization).
The text was updated successfully, but these errors were encountered:
I was looking at CreateUsers and wondering how it was idempotent because it wasn't obvious to me that the
name
field was unique.https://github.com/bufbuild/registry-proto/blob/601ec088649be87ee6a683602fe1e6ecc587a665/buf/registry/owner/v1beta1/user_service.proto#L82-L89
I went to look at the definition of User and still wasn't obvious the name was intended to be unique since the field documentation didn't indicate that either. I did eventually find the docs on the User type itself, but those docs are actually not very close to the field documentation:
https://github.com/bufbuild/registry-proto/blob/601ec088649be87ee6a683602fe1e6ecc587a665/buf/registry/owner/v1beta1/user.proto#L23-L42
Furthermore, I kind of expect "id" like fields to be first in the definition of a type.
Similar situation for Organization.name too.
Here are some things that we could do to improve the situation for both
User
andOrganization
(not mutually exclusive, could to some or all of them).Move the uniqueness documentation to the `name` field on `User` and `CreateUsersRequest.Value`
Move `name` to be field 2 so it is next to `id`
Consider naming the field `username` or `handle` instead of `name`
handle
is potentially better because it works for organizations too (username
would be a more awkward on anOrganization
).The text was updated successfully, but these errors were encountered: