Create Data Models For initial entities

[bketelsen]

See wiki for initial list of entities.

[bketelsen]

Data models in Protobufs v3 for GRPC/GoKit compatibility

[eduncan911]

https://github.com/gopheracademy/congo/wiki/System-Entities

Reading over the list, how about for Attendees:

Attendee

• contact info
• belongs to an event
• can attend multiple events
• can attend be a member of multiple conferences
• be notified of new events for a specific conference (subscribe/opt-in)

EDIT:
In other words, a single "attendee" shared across all conferences and events?

Or perhaps, a single "attendee" per conference, shared across multiple events?
^- this last option would keep it multi-tenant in nature, not sharing users.

[bketelsen]

What is being a "member of multiple conferences"?

[bketelsen]

WIP of one entity at github.com/bketelsen/congo (see /series/series.go)

[flowchartsman]

So we don't have to jump around, here is the list of entities

[eduncan911]

@bketelsen

I was thinking of scratching that, per my last comment (in the edit). To keep it multi-tenanted "conferences", an attendee would only belong to a single conference - not multiples.

[bketelsen]

I think it's probably best to keep users assigned at a SERIES level
Repeat GopherCon attendees can save some registration time, but registering for OSCON you'd create a new "account" which belonged to the OSCON series

[flowchartsman]

Something like this maybe? Then, depending on context, you could just not send the full list of activities or people. For example, when viewing an activity, all attendees have empty attending, and when viewing a person, all attending entries would have empty attendees.

message Activity {
  required int64 id = 1;
  required string name = 2;
  repeated Person attendees = 3;
  //etc.
}
message Person {
  required int64 id = 1;
  required string fname = 2;
  required string lname = 3;
  optional string email = 4;
  repeated Activity attending = 5;
  //etc.
}

[flowchartsman]

Or, if you wanted to avoid context switching, omit the repeateds above and go with relational messages? Someone with more protobuf experience want to chime in?

message ActivityDetails {
  required Activity activity = 1;
  repeated Person attendees = 2;
  //etc
}

[bketelsen]

I like the relational messages better

[bketelsen]

so @alaska are you taking the first stab at the entities while @eduncan911 works on the first pass of the router/REST bits?

[eduncan911]

I think we should keep the same domain naming conventions.

person renamed to attendee?
On May 24, 2015 2:07 PM, "Brian Ketelsen" [email protected] wrote:

so @alaska https://github.com/alaska are you taking the first stab at
the entities while @eduncan911 https://github.com/eduncan911 works on
the first pass of the router/REST bits?

—
Reply to this email directly or view it on GitHub
#2 (comment).

[flowchartsman]

Sure thing. That was only an illustrative example anyway. I'll get a pull request out sometime this evening or tomorrow.

[eduncan911]

@bketelsen yep, the first pass will be stubs for whatever we'll want inside

[bketelsen]

https://github.com/frab/frab/blob/master/db/schema.rb
Someone else was kind enough to think through this -- as pointed out by @brianredbeard

[brianredbeard]

One thing I would call out is making more of the fields optional. (i.e. 'gender' was required in the original and I committed specific changes to our copy to make it optional). It's good as a starter framework.

[flowchartsman]

No worries there, at least if we're still committed to this protobuf thang. All fields are optional in proto3. "required" and "optional" no longer have any meaning to protobuf.

[flowchartsman]

I'm guessing protobuf has been abandoned since the messages dir and accompanying files have been removed. Should we close this issue, or continue it forward with the revised scheme?

[bketelsen]

let's keep it open, since it isn't protobuf specific. I'm trying goa [1] on for size right now

[1] goa.design