Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce touched_at DateTime property #1

Closed
Sibyx opened this issue Aug 28, 2021 · 0 comments
Closed

Introduce touched_at DateTime property #1

Sibyx opened this issue Aug 28, 2021 · 0 comments
Labels
enhancement New feature or request

Comments

@Sibyx
Copy link
Collaborator

Sibyx commented Aug 28, 2021

Currently to fill <updated> of the OPDS catalog we use the updated_at property of objects (Catalog, Feed, Entry). This is not a good idea, because the updated_at property reflects the last change of the particular object in terms of ORM. This value is not updated if a new entry was added to the catalog. This kind of behavior may confuse the consumers of the API because feeds look inactive.

Solution

My solution to the problem is to implement touched_at property for these models:

  • Catalog,
  • Feed,
  • Entry.

This property should be updated accordingly to the catalog hierarchy if something "dramatically" changes, for example:

  • new acquisition was created,
  • new entry was created.

Implementation considerations

Django Signals looks pretty good for handling required events.

Property can be stored inside the database or we can use Redis as a cache server for such value (access is supposed to be faster in case of rendering catalog).

@Sibyx Sibyx added the enhancement New feature or request label Aug 28, 2021
@Sibyx Sibyx changed the title Introduce changed_at DateTime property Introduce touched_at DateTime property Jan 28, 2024
@Sibyx Sibyx closed this as completed Feb 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: Done
Development

No branches or pull requests

1 participant