Subscriptions architectural choice

Created on 24 May 2024, about 1 month ago
Updated 3 June 2024, about 1 month ago

Problem/Motivation

Firstly, I want to commend you on the interesting module you have created!
I want to discuss the decision to introduce a new content type (page_notify_subscriptions) rather than storing the subscription as a custom entity and storing this in a custom table.

Data model changes

Understanding the rationale behind this choice is crucial for me.

Could you please elaborate on the reasons for opting for a content type? Specifically:
- What advantages does a content type provide over custom entities in this context?
- Would you be open to considere an alternative approach; Storing subscriptions in database as custom entities instead?

πŸ“Œ Task
Status

Active

Version

3.0

Component

Code

Created by

πŸ‡³πŸ‡±Netherlands robbertnl

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @robbertnl
  • πŸ‡ΊπŸ‡ΈUnited States risweb

    Hey robbertnl,

    Thank you for your feedback! There isn't a strong reason behind this choice (to use a content type). The main reason was to use subscriptions nodes in views, and that seamed to me like an easier way to do that. I am open to have this module store subscriptions as a custom entity and in a custom table. It will take some time to rewrite the code.
    Let me know what are your thoughts.

  • πŸ‡³πŸ‡±Netherlands robbertnl

    Hi @risweb

    For creating custom entities you could use https://www.drush.org/12.x/generators/entity_content/ as a starting point (Beside the documentation offcourse).

    Would you be open to allow patches/integration for
    - decoupled use ( i am working on a decoupled project)
    - using/defining events before sending notifications (for my usecase i want to send only updates if a specified field has changed)

Production build 0.69.0 2024