I wanted to implement a notification system for our school, it's a php/mysql webapp that is not opened for public, so it doesn't receive much traffic. "daily 500-1000 visitor".
1. My initial approach was using MYSQL triggers:
I used a Mysql AFTER INSERT trigger to add records to a table named notifications. Something like.
'CREATE TRIGGER `notify_new_homwork` AFTER INSERT ON `homeworks`
FOR EACH ROW INSERT INTO `notifications`
( `from_id`, `note`, `class_id`)
VALUES
(new.user_id,
concat('A New homework Titled: "',left(new.title,'50'),
'".. was added' )
,new.subject_id , 11);'
This kind of black magic worked very well, yet i couldn't keep track of if this notification is new "to show count of new notifications for user".
so i added a page named notifications.
Notifications are retrieved with something like
SELECT n.* from notifications n
JOIN user_class on user_class.class_id = n.class_id where user_class.user_id = X;
Note: table user_class link user to class "user_id,class_id,subject_id" -subject is null unless user is a teacher'
Now my next challenges are.
how to keep track of new vs old notifications per user?
how can i aggregate notifications that are similar to user into one row ?
example if 2 user commented on something, then do not insert a new row, just update the old one with something like 'userx and 1 other commented on hw'.
Thanks alot
Edit
As per answer below, to set a read/unread flag on row, i will need to have a row for each student not just a row for the whole class.. which means editing the trigger to something like
insert into notifications (from_id,note,student_id,isread)
select new.user_id,new.note,user_id,'0' from user_class where user_class.class_id = new.class_id group by user_class.user_id
Well this question is 9 months old so i'm not sure if OP is still in the need of an answer but due the many views and the tasty bounty I would like to also add my mustard (German saying..).
In this post I will try to make a simple explained example on how to start building a notification system.
Edit: Well ok this turned out way, way, way longer than I expected it to be. I got really tired in the end, i'm sorry.
WTLDR;
Question 1: have a flag on every notification.
Question 2: Still store every notification as a single record inside your database and group them when they are requested.
Structure
I assume that the notifications will look something like:
+---------------------------------------------+
| ▣ James has uploaded new Homework: Math 1+1 |
+---------------------------------------------+
| ▣ Jane and John liked your comment: Im s... |
+---------------------------------------------+
| ▢ The School is closed on independence day. |
+---------------------------------------------+
Behind the curtains this could look something like this:
+--------+-----------+--------+-----------------+-------------------------------------------+
| unread | recipient | sender | type | reference |
+--------+-----------+--------+-----------------+-------------------------------------------+
| true | me | James | homework.create | Math 1 + 1 |
+--------+-----------+--------+-----------------+-------------------------------------------+
| true | me | Jane | comment.like | Im sick of school |
+--------+-----------+--------+-----------------+-------------------------------------------+
| true | me | John | comment.like | Im sick of school |
+--------+-----------+--------+-----------------+-------------------------------------------+
| false | me | system | message | The School is closed on independence day. |
+--------+-----------+--------+-----------------+-------------------------------------------+
Note: I don't recommend to group the notifications inside the database, do that on runtime this keeps things a lot more flexible.
Unread
Every notification should have a flag to indicate if the recipient has already opened the notification.
Recipient
Defines who receives the notification.
Sender
Defines who triggered the notification.
Type
Instead of having every Message in plain text inside your database create types. This way you can create special handlers for different notification types inside your backend. Will reduce the amount of data stored inside your database and gives your even more flexibility, enabled easy translating of notification, changes of past messages etc..
Reference
Most notifications will have a Reference to a record on your database or your application.
Every system I have been working on had a simple 1 to 1 reference relationship on a notification, you might have an 1 to n keep in mind that I will continue my example with 1:1. This also means that I don't need a field defining what type of object is referenced because this is defined by the notification type.
SQL Table
Now when defining a real table structure for SQL we come to a few decisions in terms of the database design. I will go with simplest solution which will look something like this:
+--------------+--------+---------------------------------------------------------+
| column | type | description |
+--------------+--------+---------------------------------------------------------+
| id | int | Primary key |
+--------------+--------+---------------------------------------------------------+
| recipient_id | int | The receivers user id. |
+--------------+--------+---------------------------------------------------------+
| sender_id | int | The sender's user id. |
+--------------+--------+---------------------------------------------------------+
| unread | bool | Flag if the recipient has already read the notification |
+--------------+--------+---------------------------------------------------------+
| type | string | The notification type. |
+--------------+--------+---------------------------------------------------------+
| parameters | array | Additional data to render different notification types. |
+--------------+--------+---------------------------------------------------------+
| reference_id | int | The primary key of the referencing object. |
+--------------+--------+---------------------------------------------------------+
| created_at | int | Timestamp of the notification creation date. |
+--------------+--------+---------------------------------------------------------+
Or for the lazy folks the SQL create table command for this example:
CREATE TABLE `notifications` (
`id` int(11) unsigned NOT NULL AUTO_INCREMENT,
`recipient_id` int(11) NOT NULL,
`sender_id` int(11) NOT NULL,
`unread` tinyint(1) NOT NULL DEFAULT '1',
`type` varchar(255) NOT NULL DEFAULT '',
`parameters` text NOT NULL,
`reference_id` int(11) NOT NULL,
`created_at` int(11) NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
PHP Service
This implementation depends completely on the needs of your application, Note: This is an example not the golden standard on how to build an notification system in PHP.
Notification model
This is an example base model of the notification itself, nothing fancy just the needed properties and the abstract methods messageForNotification and messageForNotifications we expected being implemented in the different notification types.
abstract class Notification
{
protected $recipient;
protected $sender;
protected $unread;
protected $type;
protected $parameters;
protected $referenceId;
protected $createdAt;
/**
* Message generators that have to be defined in subclasses
*/
public function messageForNotification(Notification $notification) : string;
public function messageForNotifications(array $notifications) : string;
/**
* Generate message of the current notification.
*/
public function message() : string
{
return $this->messageForNotification($this);
}
}
You will have to add a constructor, getters, setters and that kind of stuff by yourself in your own style, i'm not going to provide a ready to use Notification system.
Notification Types
Now you can create a new Notification subclass for every type. This following example would handle the like action of a comment:
Ray has liked your comment. (1 notification)
John and Jane liked your comment. (2 notifications)
Jane, Johnny, James and Jenny liked your comment. (4 notifications)
Jonny, James and 12 others liked your comment. (14 notifications)
Example implementation:
namespace Notification\Comment;
class CommentLikedNotification extends \Notification
{
/**
* Generate a message for a single notification
*
* #param Notification $notification
* #return string
*/
public function messageForNotification(Notification $notification) : string
{
return $this->sender->getName() . 'has liked your comment: ' . substr($this->reference->text, 0, 10) . '...';
}
/**
* Generate a message for a multiple notifications
*
* #param array $notifications
* #return string
*/
public function messageForNotifications(array $notifications, int $realCount = 0) : string
{
if ($realCount === 0) {
$realCount = count($notifications);
}
// when there are two
if ($realCount === 2) {
$names = $this->messageForTwoNotifications($notifications);
}
// less than five
elseif ($realCount < 5) {
$names = $this->messageForManyNotifications($notifications);
}
// to many
else {
$names = $this->messageForManyManyNotifications($notifications, $realCount);
}
return $names . ' liked your comment: ' . substr($this->reference->text, 0, 10) . '...';
}
/**
* Generate a message for two notifications
*
* John and Jane has liked your comment.
*
* #param array $notifications
* #return string
*/
protected function messageForTwoNotifications(array $notifications) : string
{
list($first, $second) = $notifications;
return $first->getName() . ' and ' . $second->getName(); // John and Jane
}
/**
* Generate a message many notifications
*
* Jane, Johnny, James and Jenny has liked your comment.
*
* #param array $notifications
* #return string
*/
protected function messageForManyNotifications(array $notifications) : string
{
$last = array_pop($notifications);
foreach($notifications as $notification) {
$names .= $notification->getName() . ', ';
}
return substr($names, 0, -2) . ' and ' . $last->getName(); // Jane, Johnny, James and Jenny
}
/**
* Generate a message for many many notifications
*
* Jonny, James and 12 other have liked your comment.
*
* #param array $notifications
* #return string
*/
protected function messageForManyManyNotifications(array $notifications, int $realCount) : string
{
list($first, $second) = array_slice($notifications, 0, 2);
return $first->getName() . ', ' . $second->getName() . ' and ' . $realCount . ' others'; // Jonny, James and 12 other
}
}
Notification manager
To work with your notifications inside your application create something like a notification manager:
class NotificationManager
{
protected $notificationAdapter;
public function add(Notification $notification);
public function markRead(array $notifications);
public function get(User $user, $limit = 20, $offset = 0) : array;
}
The notificationAdapter property should contain the logic in direct communication with your data backend in the case of this example mysql.
Creating notifications
Using mysql triggers is not wrong, because there is no wrong solution. What works, works.. But I strongly recommend to not let the database handle application logic.
So inside the notification manager you might want to do something like this:
public function add(Notification $notification)
{
// only save the notification if no possible duplicate is found.
if (!$this->notificationAdapter->isDoublicate($notification))
{
$this->notificationAdapter->add([
'recipient_id' => $notification->recipient->getId(),
'sender_id' => $notification->sender->getId()
'unread' => 1,
'type' => $notification->type,
'parameters' => $notification->parameters,
'reference_id' => $notification->reference->getId(),
'created_at' => time(),
]);
}
}
Behind the add method of the notificationAdapter can be a raw mysql insert command. Using this adapter abstraction enables you to switch easily from mysql to a document based database like mongodb which would make sense for a Notification system.
The isDoublicate method on the notificationAdapter should simply check if there is already a notification with the same recipient, sender, type and reference.
I cannot point out enough that this is only a example. (Also I really have to shorten the next steps this post is getting ridiculously long -.-)
So assuming you have some kind of controller with an action when a teacher uploads homework:
function uploadHomeworkAction(Request $request)
{
// handle the homework and have it stored in the var $homework.
// how you handle your services is up to you...
$notificationManager = new NotificationManager;
foreach($homework->teacher->students as $student)
{
$notification = new Notification\Homework\HomeworkUploadedNotification;
$notification->sender = $homework->teacher;
$notification->recipient = $student;
$notification->reference = $homework;
// send the notification
$notificationManager->add($notification);
}
}
Will create a notification for every teacher's student when he uploads a new homework.
Reading the notifications
Now comes the hard part. The problem with grouping on the PHP side is that you will have to load all notifications of the current user to group them correctly. This would be bad, well if you have only a few users it would probably still be no problem, but that doesn't make it good.
The easy solution is to simply limit the number of notifications requested and only grouping these. This will work fine when there are not many similar notifications (like 3-4 per 20). But lets say the post of a user / student gets about a hundred likes and you only select the last 20 notifications. The user will then only see that 20 people liked his post also that would be his only notification.
A "correct" solution would be grouping the notifications already on the database and selecting only some samples per notification group. Than you would just have to inject the real count into your notification messages.
You probably didn't read the text below so let me continue with a snippet:
select *, count(*) as count from notifications
where recipient_id = 1
group by `type`, `reference_id`
order by created_at desc, unread desc
limit 20
Now you know what notifications should be around for the given user and how many notifications the group contains.
And now the shitty part. I still could not find out a better way to select a limited number of notifications for each group without doing a query for every group. All suggestions here are very welcome.
So I do something like:
$notifcationGroups = [];
foreach($results as $notification)
{
$notifcationGroup = ['count' => $notification['count']];
// when the group only contains one item we don't
// have to select it's children
if ($notification['count'] == 1)
{
$notifcationGroup['items'] = [$notification];
}
else
{
// example with query builder
$notifcationGroup['items'] = $this->select('notifications')
->where('recipient_id', $recipient_id)
->andWehere('type', $notification['type'])
->andWhere('reference_id', $notification['reference_id'])
->limit(5);
}
$notifcationGroups[] = $notifcationGroup;
}
I will now continue assuming that the notificationAdapters get method implements this grouping and returns an array like this:
[
{
count: 12,
items: [Note1, Note2, Note3, Note4, Note5]
},
{
count: 1,
items: [Note1]
},
{
count: 3,
items: [Note1, Note2, Note3]
}
]
Because we always have at least one notification in our group and our ordering prefers Unread and New notifications we can just use the first notification as a sample for rendering.
So to be able to work with these grouped notifications we need a new object:
class NotificationGroup
{
protected $notifications;
protected $realCount;
public function __construct(array $notifications, int $count)
{
$this->notifications = $notifications;
$this->realCount = $count;
}
public function message()
{
return $this->notifications[0]->messageForNotifications($this->notifications, $this->realCount);
}
// forward all other calls to the first notification
public function __call($method, $arguments)
{
return call_user_func_array([$this->notifications[0], $method], $arguments);
}
}
And finally we can actually put most of the stuff together. This is how the get function on the NotificationManager might look like:
public function get(User $user, $limit = 20, $offset = 0) : array
{
$groups = [];
foreach($this->notificationAdapter->get($user->getId(), $limit, $offset) as $group)
{
$groups[] = new NotificationGroup($group['notifications'], $group['count']);
}
return $gorups;
}
And really finally inside a possible controller action:
public function viewNotificationsAction(Request $request)
{
$notificationManager = new NotificationManager;
foreach($notifications = $notificationManager->get($this->getUser()) as $group)
{
echo $group->unread . ' | ' . $group->message() . ' - ' . $group->createdAt() . "\n";
}
// mark them as read
$notificationManager->markRead($notifications);
}
Answer:
Introduce a read/unread variable on the notification. You can then pull only unread notifications by doing ... WHERE status = 'UNREAD' in your sql.
You can't really... you will want to push that notification. What you can do is still aggregate them though by using GROUP BY. You would likely want to group on something unique like a new homework so it might be something like ... GROUP BY homework.id
You can solve the issue with making a NotificationsRead table, containing the ID of the user and the ID of the notification the user wanted to mark as read.
(This way you can keep each students and the teacher separated.)
Then you can join that table to your notification's table and you will know if it should be considered old or new.
geggleto's answer was right about the second part, you can grab the notifications with SELECT *, COUNT(*) AS counter WHERE ... GROUP BY 'type' then you will know how many of the same type you have there and you can prepare the 'userx and 1 other commented on hw' on view.
I'd also suggest you not to store the whole text you want to display, store the required information instead, like: from_id, class_id, type, name and so - this way you can change mechanisms easier later if you need to, and you have to store less.
For those who are looking for a way to not use an app, you can use vanilla PHP and MySQL without using an application. Upon adding a piece of homework, you can add a notification. (yes I know this is open to SQL injection but I'm using regular MySQL for simplicity sake)
SQL for when someone adds homework:
$noti_homework = "INSERT INTO homework(unread, username, recipient, topic) VALUES(true, user_who_added_hw, user_who_receives_notification, homework_name);
Then you can check whether the notification is unread:
$noti_select = "SELECT FROM homework WHERE recipient='".$_SESSION['username']."' AND unread='true'";
$noti_s_result = $conn->query($noti_select);
$noti_s_row = $noti_s_result = $noti_s_result->fetch_assoc();
if ($noti_s_row['unread'] == true) {
}
Finally, you can echo the notification if it's true.
if ($noti_s_row['unread'] == true) {
echo $noti_s_row['username'] . " has sent out the homework " . $noti_s_row['homework'] . ".";
}
The method for liking a comment is pretty similar and in fact a lot easier.
$noti_like = "INSERT INTO notification_like(unread, username, recepient), VALUES(true, user_who_followed, user_who_recieves_notification);
You then just follow the same pattern of echoing the rows like so:
$noti_like = "INSERT INTO notification_like(unread, username, recipient), VALUES(true, user_who_followed, user_who_receives_notification);
$noti_like_select = "SELECT FROM notification_like WHERE recipient='".$_SESSION['username']."' AND unread='true'";
$noti_l_result = $conn->query($noti_like_select);
$noti_l_row = $noti_s_result = $noti_l_result->fetch_assoc();
if ($noti_l_row['unread'] == true) {
echo $noti_l_row['username'] . " has liked your topic!";
}
Then for getting amount of notifications:
$count_like = "SELECT COUNT(*) FROM notification_like WHERE recipient='".$_SESSION['username']."' AND unread='true'";
$num_count = $count_like->fetch_row();
$count_hw = "SELECT COUNT(*) FROM homework WHERE recipient='".$_SESSION['username']."' AND unread='true'";
$num_count_hw = $count_hw->fetch_row();
Using PHP you can echo the two variables, $num_count and $num_count_hw.
$num_count_real = $num_count[0];
$num_count_hw_real = $num_count_hw[0];
echo $num_count_real + $num_count_hw_real;
None of this code is tested FYI. Hope this helped :)
I am trying to send and email to multiple users. These users can have the same ID sometimes. If the email is sent to this user, then instead sending 2 emails, only send one email to the users and move the next user to send the email.
$cusItems = DB::("Select * from items");
//we will assume:
//userid email item
// 2 k#gmail.com eggs
// 4 m#yahoo.com sugar
// 2 k#gmail.com milk
foreach ($cusItems as $key) {
$uEmail = $key->email;
$id = $key->userid;
data = [
'email' => $key->email,
'item' => $key->item,
];
Mail::send(['html'=>'emailTemp'], $data , function($message) use ($uEmail, $id) { $message->to($uEmail, 'Your Items')->subject('Items #'. $id); $message->from('u2345245#deakincollege.com.au','Semester4'); }); }
then the email should be:-
when sent to user ID 2.
First email template:-
to: k#gmail.com
sub: XXX
Hi,
Your Items are :-
eggs
milk
thanks
second email template:-
to: m#yahoo.com
sub: XXX
Hi,
Your Items are :-
sugar
thanks
Please let me know if I a not clear, my native language is not english and i have tried my best to explain. thanks
You have to remove the duplicates from the query it self so that you won't get any duplicate values.
your table:
userid email item itemid
2 k#gmail.com eggs 1
4 m#yahoo.com sugar 2
2 k#gmail.com milk 3
Change your query into
SELECT userid,email,GROUP_CONCAT(item) as items,GROUP_CONCAT(itemid) as itemids FROM `items` GROUP BY userid
This will give you the following result. All you have to do is loop the query and send the mail with the items that are there for each user in one email.
userid email items itemids
2 k#gmail.com eggs,milk 1,3
4 m#yahoo.com sugar 2
I hope this will help you to solve your issue.
I'm using OctoberCMS based on Laravel, with the official User plugin.
I'm making a gallery where frontend users can upload files.
The user is the owner of their uploaded file and is the only one that has permission to edit.
My question, is this the correct way to design and handle user record ownership? All user upload records will be mixed together in one database table mysite_gallery_ and will be sorted and displayed in html with filters, such as viewing all uploads by a specific username.
Will this be slow? Should each user have their own table? Will it be secure enough to prevent another user, bot, or hack script from editing a file record they don't own?
MySQL Table
All upload records are saved to the table mysite_gallery_.
| id | username | filename | slug | title | tags |
| ---- | ---------- | ---------- | -------- | --------- | -------------------- |
| 1 | matt | xyz123 | xyz123 | My File | space, galaxy, stars |
Record Ownership
At upload, my custom Upload component uses Laravel to create a record in the database of the file's title, slug, tags, etc.
To define ownership I have the Upload component save the user's username to the record.
# Get Current User
$user = '';
if (Auth::check()) {
$user = Auth::getUser();
$user = $user->username;
}
# Create Record
$gallery = new Gallery();
$gallery->username = $user;
$gallery->filename = $name;
$gallery->title = $title;
$gallery->slug = $slug;
$gallery->tags = $tags;
$gallery->save();
Edit Record
If the user wants to edit the file properties, such as title, Laravel checks if current user matches the username in the record. If user is owner, it allows edit.
# Get File Record Owner
$owner = '';
if (Gallery::where('filename', '=', $filename)->exists()) {
$record = Gallery::where('filename', '=', $filename)->first();
$owner = $record->username;
}
# Authenticate Current User is Owner
$is_owner = false;
if (Auth::check()) {
# Get Current User
$user = Auth::getUser();
# Check if User is Owner
if ($user->username == $owner) {
$is_owner = true;
}
}
# Edit Record
if ($is_owner == true) {
# Update Record
Gallery::where('filename', '=', $filename)->update(['title' => $title]);
return Redirect::back();
}
It is a better idea to use the users id instead of the username. It'll take less space in the database and is also faster.
Also I would put the tags in another table. Although this depends on how you use the tags. If you have them in another table then it would be easier to get all the uploads for a tag for example.
I've tried to query using laravel eloquent where user is following a specific brand.
The problem: How to query listing of brand and let me know if current login user is following the brand?
got 3 tables:
Brand:
Id | name | logo
User:
Id | name | email | password
Followers:
brand_id | user_id
Now i tried to query all brand and inside of the collection i want to add
is_follow = 1 or is_follow = 0
if the user already follow or 0 if not exists.
I'm using fractal so maybe it can be easier to query. but i don't really get it how to query it out with check the user_id first.
Thanks
*Update
I manage to solve it. But i think its a bad practice.
$user_id = Request::get('user_id');
foreach($brands->followers as $value){
$array[] = $value->user_id;
}
if(in_array($user_id, $array)){
$is_follow = 1;
}
You can check if the authenticated User follows a specific Brand with:
$user = Auth::user();
$exists = $user->brands->contains($brand_id);
You can also do it with a raw query which will be better in terms of performance:
$exists = DB::table('user_brand')
->whereBrandId($brand_id)
->whereUserId(Auth::user()->id)
->count() > 0;
I'm building a messaging system using ReadBean 3.5.1 (with MySQL). Each user can have multiple messages, so this is a simple one-to-many relationship for RedBean, like so:
$sender = R::load('user', 1);
$message = R::dispense('message');
$message->stuff = "Hello world";
$sender->ownMessage[] = $message;
What I want to do now is associate the recipient user with the message using a RedBean abstraction. I can get the ID of the recipient and store it in a column in the messages table manually, but is there a way I can do this with RedBean instead?
The solution to this is actually a bit backwards to what was posted. You need to create a message and assign two user models to it instead of the other way round. Here's an example:
// Make some models
list($sender, $recipient) = R::dispense('user', 2);
$message = R::dispense('message');
// Set some data
$sender->name = 'Sender';
$recipient->name = 'Recipient';
$message->title = "Hello world";
// Associate users and message
$message->sender = $sender;
$message->recipient = $recipient;
// Store everything
R::store($message);
Really easy. RedBean takes care of storing the updated user info when R::store($message) is called. The messages table then looks like this:
+----+-------------+-----------+--------------+
| id | title | sender_id | recipient_id |
+----+-------------+-----------+--------------+
| 6 | Hello world | 3 | 4 |
+----+-------------+-----------+--------------+