Skip to content

Branch etag can be inconsistent in what it represents #162

@dlamoris

Description

@dlamoris

Currently a branch's etag gets updated when the model updates (whether via sparql update or model load) and via ldp patch updating its metadata. If a client is relying on this to determine if a branch model data changed this can be confusing.

A possible solution is to have a second etag triple (ex. modelEtag or contentEtag) that represents the model content. For ldp endpoints the metadata etag would be used, and for sparql/gsp endpoints the modelEtag would be used.

This is considering the use case for an etag (cacheing or checking for if content has changed) - for an ldp endpoint the apis modify/get the metadata, so an etag used here should only be representing changes in metadata.

For gsp/sparql endpoints the etag should represent the model content.

For this to be consistent, this means that a model commit/model load - even if it's a gsp/sparql endpoint, should be updating both etags since the commit updated the metadata of the branch as well as the model content. But an ldp patch would only update the etag of the 'metadata' etag and not the 'content' etag.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    Backlog

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions