Repo #3
Repo #3
Conversation
…on' into complete-repository-implementation
| @@ -11,18 +11,22 @@ const ( | |||
| Decommisioned // Removed from PROD | |||
| ) | |||
|
|
|||
| type ImplementationStatusDictionary struct { | |||
| Id ImplementationStatus `sql:",pk"` | |||
| Status string // Arbitrary name/tag for the source system | |||
| SourceSystem *SourceSystem | ||
| } | ||
|
|
||
| // Definition of a field/attribute within the wide-row structure. | ||
| // This structure represents the canonical definition of the field. | ||
| type Field struct { | ||
| Id uint64 `json:"-"` | ||
| Name string `sql:",unique"` // The name of a field according to the wide-row design | ||
| Name string `sql:",pk"` // The name of a field according to the wide-row design |
There was a problem hiding this comment.
How are you going to distinguish between 2 fields with the same name - the first one being a 'top level' field and the the other one being nested somewhere? Will Name contain the entire field path so field_A and field_B.field_A will end up having different Names?
| GetEventTypes() ([]model.EventType, error) | ||
| GetFields() ([]model.Field, error) | ||
| GetEventTypeImplementations(sourceSystemName string) ([]model.EventTypeImplementation, error) | ||
| GetFieldImplementations(sourceSystemName string, fieldName string) ([]model.FieldImplementation, error) |
There was a problem hiding this comment.
Should it really be taking sourceSystemName? fieldImplementation is already connecting a sourceSystem with a field so if you provide both sourceSystemName and fieldName to this function you'll end up with either 0 or 1 FieldImplementations.
Edit: OK, my bad - I didn't notice the EventTypeName in fieldImplementation... maybe because I'm not convinced that it's a good idea to have it there in the first place.
No description provided.