The Notification Model - Part II

( I am so sleepy right now, didn't slept wel last night. )

There were one question left to answer.

What does this notification_followers do? Aside from get, There's still some functions provided by NotificationCenter:

<?php // ajax-notification.php
// Read
$ntc->notificationRead($_POST['id']);
// Enable
$ntc->enableNotification($session->user_id, $_POST['tid'], $_POST['cid']);
// Disable
$ntc->disableNotification($session->user_id, $_POST['tid'], $_POST['cid']);
// GetStats
$ntc->getTypeStats($session->user_id);

When a notification get pushed. It must have something to do with the `notification_followers` table. It must use have a way to check whether the notification could be pushed to the target subscribers:

<?php // NotificationCenter.php
class NotificationCenter {
...

    public function pushNotification($user_id = 0, NotificationModel $n) {
        return $this->dbh->exec($n->dispatchNotification($user_id));
    }
...

<?php // UserCommentNotice.php
...
class UserCommentNotice extends Notification implements NotificationModel {
    const ID = 1;
...
    const KEY_JOINT = " LEFT JOIN articles a ON nf.constraint_id=a.article_id";
...
    public function dispatchNotification($user_id = 0) {
        // UserCommentNotice
        // DO NOT dispatch to user when
        //   1. Article belong to user, user comment to guests comments
        //
        return $this->dispatchNotice(self::ID, self::KEY_JOINT, "AND nf.user_id <> $user_id");
    }
...

<?php // Notifaction.php
...
class Notification {
...
    protected $cid = 0;
    protected $did = 0;
...
    protected function dispatchNotice($note_id, $JOINT = "", $COND = "") {
        // Problem: We cannot dispatch events for guest since we can't identify that email address is belong to that user
        // thus we cannot deliver the email through NotificationCenter.
        // Even if we validate the email, but still other user could type in that email address and blow off who ever that
        // email is belonged to. So this is impossible.
        // Unless we make a login system
        return <<<___SQL___
            INSERT INTO notifications (user_id, notify_id, carrier_id, timestamp)
                SELECT DISTINCT nf.user_id, nf.notify_id, {$this->did}, {$GLOBALS['timestamp']}
                    FROM notification_followers nf
                    $JOINT
                WHERE nf.type_id=$note_id AND nf.constraint_id={$this->cid} $COND
___SQL___;

    }
...

So the checking condition is defined inside the SQL:

WHERE nf.type_id=$note_id AND nf.constraint_id={$this->cid} $COND

Awesome, it can be done in one single query. From here I can see the each row of `notification_followers` refers to a subscription to that unique object for a specific type of notification.

In the following example again I use the `UserCommentNotice`( type_id = 1 ).
Lets say there is someone commented on an article with id

mysql> SELECT * FROM notification_followers WHERE `constraint_id` = 1790;
+-----------+---------+---------+---------------+
| notify_id | user_id | type_id | constraint_id |
+-----------+---------+---------+---------------+
|      1037 |       2 |       1 |          1790 |
+-----------+---------+---------+---------------+
1 row in set (0.00 sec)

If the row above does not exists, then the WHERE condition returns Null thus the INSERT query is discarded. Where the constraint_id is defined by NotifactionModel.
If the row above returns more multiple rows, that means there are multiple user subscribed to this type of notification with this specific constraint_id.

When a guest commented on an article, this inserts(push) a row(notification) with that comment_id (carrier_id) to the notification table for the `article_id` (constraint_id) 1790 for every users that is subscribed to this article.

I think this model is entirely dedicated to Table structure. The next goal is to examine the viability to take this structure into Rosemary.

Continue to "The Notification Model" Part III >>

Here's the attached files for download:

Tag(s): php cranberry MySQL

斟酌鵬兄

Fri Aug 21 2015 07:10:47 GMT+0000 (Coordinated Universal Time)

Last modified: Fri Mar 11 2016 14:31:57 GMT+0000 (Coordinated Universal Time)