[MGNLGQL-10] GraphQL serves system and metadata properties Created: 13/May/20  Updated: 18/Nov/20  Resolved: 06/Nov/20

Status: Closed
Project: Magnolia GraphQL
Component/s: None
Affects Version/s: None
Fix Version/s: 1.0

Type: Story Priority: Neutral
Reporter: Christopher Zimmermann Assignee: Jaroslav Simak
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
causality
is causing MGNLGQL-57 DOC: Support for system and metadata ... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Documentation update required:
Yes
Date of First Response:
Epic Link: GraphQL Phase 1
Sprint: HL & LD 14, HL & LD 15
Story Points: 3

 Description   

User story:

As a developer, I want some system and metadata properties available so that I have a consistent way to get these things.

Notes:

Consider putting all system/metadata properties under their own node, this can make it easier for client developers to keep metadata and actual content separate.

_ underscores seem to be commonly used for these cases.

Acceptance criteria:

  • Implement at least partial support for metadata mentioned: @id, @path, @name, @nodeType
  • GraphiQL is strict about property names, so we need a new convention rather then using colons and at-symbols as the delivery endpoint does.
  • A GUID should always be available on a response. It can be used by the client for caching on the client. It could be the node id. See: https://graphql.org/learn/caching/

 

Metadata are included on a subnode - which prevents any naming clashes with content property names:

{
  book(id: 1) {
    title
    isbn13
    _metadata {
      id
      name
      path
      nodeType
    }
  }
}

 



 Comments   
Comment by Simon Lutz [ 17/Jun/20 ]
  • Metadata are located within queried node with no prefix (mgnl or jcr), there is no metadata subnode
Comment by Christopher Zimmermann [ 23/Jun/20 ]

Isn't there a risk of a naming collision with a property of the node - like if the node had "created" as a property?

 

Comment by Christopher Zimmermann [ 23/Jun/20 ]

What about fields that the rest endpoint returns  - like @id, @path, @name, @nodeType, is something like that returned, and how are they named?

Comment by Christopher Zimmermann [ 18/Nov/20 ]

jsimak Does Beta 2 also support retriving createdBy createdAt, mgnl:tags, etcetera? 

I believe there was a way to configure this. Can you provide a link or details here on how that is configured (if it is supported)

Comment by Jaroslav Simak [ 18/Nov/20 ]

It can be configured via decoration, example path: /<my-light-module>/decorations/graphql-jcr/graphqlTypes/jcrMetadata.types.JcrMetadata.yaml, example field:

fields:
  - name: 'created'
    type:
      name: Date
      nonNull: true
    dataFetcher:
      class: info.magnolia.graphql.jcr.datafetcher.JcrPropertyDataFetcherDefinition
      propertyName: 'mgnl:created'
Generated at Mon Feb 12 05:51:40 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.