2017-01-06 3 views
1

Я только что начал экспериментировать с graphene-django/GraphQL и довольно запутался в библиотеке ретрансляции, которая была принесена для графена-джанго. После запуска примера кулинарной книги (реализации его с собственными моделями) и запуска тестового запроса в POST запрос преобразуется в странно вложенный объект с ребрами и узлами. Что это такое и что они делают?Graphene-Django: понятия соединений, краев и узлов

{ 
    companies { 
    edges { 
     node { 
     id 
    } 
    } 
    } 
} 
+0

Я также новичок в Relay. Это стандартная настройка. Проверьте это объяснение https: // facebook.github.io/relay/graphql/connections.htm – t1m0

+0

Причина, по которой этот вопрос возник, заключалась в том, что мы хотели использовать graphene-jjano в нашем приложении без зависимости от реле для фильтрации. Я смог найти технику для добавления фильтрации без использования здесь [link] (https://github.com/graphql-python/graphene/issues/215) –

+0

Я понимаю, что вы имеете в виду. Как отмечено в вашей ссылке, преимущество придерживаться соглашений о ретрансляции заключается в том, что графен дает вам предварительно настроенную настройку для подкачки. Запрос GraphQL с "pageInfo { hasNextPage hasPreviousPage startCursor endCursor }" работает автоматически. – t1m0

ответ

0

Узел

Может быть, стоит отметить, что Node является частью Facebook Relay specs (не GraphQL спецификации). Тем не менее, большинство фреймворков (включая Graphene) реализуют эту спецификацию из-за тесной связи между Relay и GraphQL.

По существу Node - это интерфейс, который реализует только поле ID, которое должно быть глобально уникальным идентификатором для объекта. ID s являются непрозрачными (типичное соглашение относится к base64('type:id')), приложения не должны пытаться полагаться на эту деталь реализации.

Node выставлен как часть корневого запроса, где приложения могут запрашивать объекты с известным ID удобным способом, например. переназначение, выбор полей, которые не были извлечены.

{ 
    node(id: ID!) { 
    ... on User { 
     id 
     userId 
     name 
    } 
    ... on Company { 
     id 
     companyId 
     owner: { 
     userId 
     name 
     } 
    } 
    ... 
    } 
} 

Это обеспечивает удобство не того, чтобы определить точку запроса для каждой модели вы разоблачить (например, message(messageId) или user(userId)). Это также позволяет запрашивать объект без пересекающих через путь объекта, например,

{ 
    user { 
    friends { 
     pages { 
     name 
     } 
    } 
    } 
} 

// vs 

{ 
    node(id) { 
    ... on Page { 
     name 
    } 
    } 
} 

Подключение

Как Node, Connection также часть Relay specs, который сделал свой путь к основному принятию.

На первый взгляд, концепция edges кажется излишней, но она решает какой-то хитрый случай использования. Подумайте о необходимости раскрывать отношения «многие ко многим», такие как «друзья», обычно реализуемые в базе данных с таблицей соединений.

+---------+   +------------+ 
| users |   | friends | 
+---------+   +------------+ 
| user_id | <------ | left_id | 
| .... | \--- | right_id | 
+---------+   | created_at | 
        +------------+ 

Теперь легко отобразить «Друзья с [дата] здесь», подвергнув friends.created_at в объекте края.

{ 
    user { 
    friends { 
     edges { 
     created_at <--- 
     user { 
      id 
      userId 
      name 
     } 
     } 
    } 
    } 
} 

edges существу определяет соотношение между nodes.

0

М2М отношения между Atable и Btable сусло будет осуществляться по третьей ссылке (присоединиться) таблицы ABLink, которая должна иметь по крайней мере, два внешних ключей:

+------+------+------------+--------+ 
| A_id | B_id | Created_at | Status | 
+------+------+------------+--------+ 

Правильно ли сказать M2M, что edge представляют такие ссылка (join) в базе данных? Итак, запрос для этого будет:

{ 
    Atable { 
    ABLink { 
     edges { 
     Created_at 
     Status 
     Btable { 
      Btable_id 
      Btable_column_1 
      Btable_column_2 
      ... 
     } 
     } 
    } 
    } 
}