Alternative to creating pages for temporary data storage

[Vineet Sawant]

Hello everyone,

I'm creating a large scale application which will be used by thousands of people. Part of of the application requires storing temporary information about user's activities. For example, if user comments on certain topic, notification of same should be given to OP and people following the topic.

I thought I'd create a subpage with a repeater field having few fields like user id, timestamp & notification status, read/unread (I just don't see why using page table is better in this case, if someone can enlighten me, that'd be great.).

But I've read that every repeater item is same as new page, so I'm really confused whether I should just start keeping temporary pages or use a page with repeater field.

But for every topic, there can be hundreds of notifications, which I think will be a problematic situation in future. So I am looking for any kind of temporary storage that will not included creating pages.

Writing logs to file could be done but i'm not sure how good solution is that and how reliable it'll be.

I'd really like a good conversation with someone who understands PW, so I'm here.

Thank you all.

[renobird]

Some quick comments.

Repeaters / PageTable seem like far too much overhead. 

Have you looked at the new comments system on the dev branch?

You mentioned temporary storage — do the topics only exist for a short time?

[Vineet Sawant]

Thanks for your reply renobird.

You mentioned temporary storage — do the topics only exist for a short time?

No, topics are permanent unless owner of the topic deletes it. The temp pages are for notifications which I want to give to the owner of the topic if someone comments or does any of other activities like adding post to favourites etc.

So basically, it's like facebook's notifications. Consider you post a photo & people are comments & liking the picture, how am I to give you notifications? I've to store all this comments/liking activity somewhere right? I've figured out a way to store comments & likes, it's just the notifications of it, which is a temporary thing, that I've to figure out.

It can be done by creating temp notification pages and add them to a notifications page array field of the post and then just check the notification status and show user the unread pages as notifications. But this way I'm wasting hell lot of page IDs. Which would be an inefficient thing to do, right?

So that's where my question comes from, how do I manage temporary storage? May be PW should provide temp pages other than usual pages with all the same features.

Sorry for the long story.

[renobird]

Ah, Seems like the least overhead would be to create a separate table for those. The lookups would be quick, even if each topic has hundreds of notifications.

[renobird]

Once each notification is marked as read, cron/lazycron could clean them out.

[Craig]

I'd perhaps use WireCache for something like this, depending on how you need to retrieve these items later on.

The most obvious method would be to key it by the user who will receive the notifications - so you would create a simple array structure with the important information for the notifications, and store it using a cache name like "notifications-1142" for user ID 1142. This should make it quick to retrieve. You can then pull this out, show it, update it by modifying the notifications array, and putting it back in the cache.

Other than that - a simple module as an interface to a custom simple database table would be more than suitable.

[Vineet Sawant]

What exactly is WireCache and where can I read more about it?

Yes, I guess I should make a table to store notifications.

[adrian]

What exactly is WireCache and where can I read more about it?

Yes, I guess I should make a table to store notifications.

https://processwire.com/blog/posts/processwire-core-updates-2.5.28/#wirecache-upgrades

and a little more hot off the press:

http://processwire.com/blog/posts/processwire-2.6-rc1-2.5.29-and-more/#whats-new-this-week-processwire-2.5.29

[SiNNuT]

It's a little hard to tell exactly how you want these notifications to work but i think the relatively new System Notifications module could be a good fit. For now it is only available on the dev branch: https://github.com/ryancramerdesign/ProcessWire/tree/dev/wire/modules/System/SystemNotifications

But in the soon to be released 2.6 it will be included i think. There isn't any formal docs yet but you can study the code and read a little bit about it here: https://processwire.com/blog/posts/processwire-2.5.3-master-2.5.4-dev/#whats-new-on-the-dev-branch

[diogo]

You could have a pagefield "notifications" in the users template, and create the notifications as pages connected to the topic (not one per user, just one per notification, that could be used for many users), than you would link the user to the notification, and delete it from the pagefield as soon as it is presented to him.

Does this make sense?

PS: I know you asked how to not create pages, but I think this way would at least make them much less, and easier to delete when not needed.

--

A little pseudo-code for the above:

foreach ($user->notifications as $not) {
    echo $not->body; // show the notification
$page->of(false);
    $user->notifications->remove($not); // remove it from the list
    if ( !$pages->get("template=user,notifications={$not}") ) $not->delete(); // if there are no more users to be notified, delete the page
}
$page->save("notifications"); //save the field with the notifications removed

Edited May 2, 2015 by diogo
Added the pseudo-code

[Vineet Sawant]

Hi diogo,

I was thinking about the notifications that PW's admin theme uses. I guess you are talking about the same thing, ain't you?

I will try your suggestion on a staging pw installation. Yesterday I gave up and wrote sql queries (which I absolutely hate to do) to store all the activity in a table called activity. Then once they are shown to user, I change the activity status to read from unread.

Since it's a different table, I don't have to worry about wasting page ids.

Thank you all for your inputs.

[SiNNuT]

Uh no, diogo was talking about something different than the admin notifications. That's actually what i was talking about. PW has notices (core/notices.php) and the more advanced SystemNotifications, available in dev but uninstalled by default.

[Vineet Sawant]

Uh no, diogo was talking about something different than the admin notifications. That's actually what i was talking about. PW has notices (core/notices.php) and the more advanced SystemNotifications, available in dev but uninstalled by default.

Oh right, I found it. 

Does this make sense?

foreach ($user->notifications as $not) {
    echo $not->body; // show the notification
$page->of(false);
    $user->notifications->remove($not); // remove it from the list
    if ( !$pages->get("template=user,notifications={$not}") ) $not->delete(); // if there are no more users to be notified, delete the page
}
$page->save("notifications"); //save the field with the notifications removed

It makes a lot of sense now.

[diogo]

Sorry, ya, that's more a frontend thing, but you could interact with the notifications system using the same method, of course.

[Can]

I implemented the SystemNotifications module on my front end, but only on the user account settings page for now to test things out..At the moment it seems to work quiet nice

$notices = $user->notifications;

then for example

$avatarErrorMsg = $notices->error("Your error message");
$avatarErrorMsg->expires = 30; // or however you like, doesn't even need to self expire
$notices->save(); // while writing this I'm not exactly sure if necessary

foreach($notices as $n)
{
    if($n->is("warning")) $messageClass = 'warning';
    if($n->is("error")) $messageClass = 'error';
    if($n->is("message")) $messageClass = 'success';
    $content .= "<div class='alert alert-$messageClass closable'>$n->title <i class='fa fa-close'></i></div>";
}