florian
06/27/2017, 8:42 AMjoar
06/27/2017, 10:03 AMCannot query field ‘enumValues’ on type ‘Field’. Did you mean ‘defaultValue’?
joar
06/27/2017, 10:04 AMjoar
06/27/2017, 10:04 AMjoao.santos
06/27/2017, 2:04 PMflorian
06/27/2017, 2:10 PMflorian
06/27/2017, 2:11 PMflorian
06/27/2017, 2:13 PMjoao.santos
06/27/2017, 2:19 PMagartha
06/27/2017, 2:34 PMagartha
06/27/2017, 2:34 PMagartha
06/27/2017, 2:35 PMflorian
06/27/2017, 2:37 PMagartha
06/27/2017, 2:39 PMagartha
06/27/2017, 2:39 PMagartha
06/27/2017, 2:39 PMflorian
06/27/2017, 2:39 PMagartha
06/27/2017, 2:39 PMflorian
06/27/2017, 2:42 PMallpwrfulroot
06/27/2017, 2:47 PMchris_r
06/27/2017, 2:48 PMflorian
06/27/2017, 2:50 PMchris_r
06/27/2017, 2:53 PMflorian
06/27/2017, 3:09 PMflorian
06/27/2017, 3:11 PMflorian
06/27/2017, 3:11 PMDocument n : 1 Translation
relationshipflorian
06/27/2017, 3:12 PMflorian
06/27/2017, 3:16 PMckelley
06/27/2017, 4:04 PMPerson
type and want to store information like phone number, email, etc. relative to that person. The obvious option would be to create a new Type for each piece of data and then to connect that type to Person
, like person.phones
, etc. However this introduces a lot of additional queries + logic on the client side (we're using Apollo) because we have to have a createX, updateX, deleteX
mutation for each piece of profile info (could use nested creates but would still need update and delete).
Another option would be to have a "superclass" called Attribute
or something where all profile info is stored. If we did this we'd differentiate by a "type=PHONE" (etc.) field on the Attribute
type. However this would likely introduce a lot of columns with null data.
Would appreciate any experience/insights on structuring those large models. Thanks everyone!jt9001
06/27/2017, 4:49 PM