Subscriptions architectural choice

Open on Drupal.org →

Created on 24 May 2024, 6 months ago

Updated 3 June 2024, 6 months 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.

architecture

Sign in to follow issues

Comments & Activities

Issue created by @robbertnl
Comment 6 months ago →
🇺🇸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.
Comment 6 months ago →
🇳🇱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)

contrib.social Blog FAQ Discussions

Production build 0.71.5 2024