Forums / Developer / What purpose do entries in the table 'eznotificationevent' have?

What purpose do entries in the table 'eznotificationevent' have?

Author Message

Paul Forsyth

Monday 04 October 2004 5:09:22 am

I've imported a whole bunch of items and now find the table 'eznotificationevent' has grown substantially. After running cronjobs, and notifications, the table is cleared.

I've tried to look around the code and apart from finding the event created as part of the publish operation i cant find a use for it. Can i safely take out the operation call to add it in the first place?

Paul

K259

Monday 04 October 2004 6:08:24 am

Hmm..we also run once a night a cronjob for sending notification-emails, but our eznotification-table is not cleared. 25273 rows in set it says.

I guess that status=0 means that notification is sent for that object.

Maybe the entries just should be deleted in the cron-job, after the sending is done?
BUT, I guess, that the purpose is that all the notificationevents are stored there, because if not all the subscribers are approved so they can receive notificationemails, they will not miss any of the notification articles if they are enabled as subscribers later on.

Paul Forsyth

Monday 04 October 2004 6:34:15 am

This is the thing, i dont think these entries play a part in the notification email. The entries are created when the object is published, which is independent from the main notification settings.

Is this part of the old notification system that was replaced by subtree notification?

paul

Paul Forsyth

Wednesday 06 October 2004 12:52:19 am

Bump

Paul Forsyth

Friday 08 October 2004 4:59:01 am

bump

i dont think this a difficult question to answer.....

paul

Paul Borgermans

Friday 08 October 2004 6:14:18 am

bump bump bump ... now I have a headache ;-)

eznotification event is filled when objects are published (or updated) when there is a corresponding/valid ezsubtree_notification_rule. After the notifications are sent, these entries are deleted. I think this table is quite general as it will hold different notification types (we have a custom one)

If it remains filled, there is probably something wrong with a ezsubtree_notification_rule , check the logs (including your php log), an error should show up.

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Paul Forsyth

Friday 08 October 2004 6:25:42 am

Humpty dumpty lives on!

In my db there is no subtree rule. The event is created on publish and then deleted when the job runs. But because im working with data import i've thousands of events in my db. Apart from being unnecessary the intial job run is very time consuming.

I think this is a bug but wanted someone from eZ to confirm. The notification system has changed over the years and i think this is a left over from the original system. But i could be wrong...

Look at the code in: kernel/content/operation_definition.php. At the bottom is the call to create an event while publishing something:

array( 'type' => 'method',
       'name' => 'create-notification',
       'frequency' => 'once',
       'method' => 'createNotificationEvent',
     )

If you follow this in: kernel/content/ezcontentoperationcollection.php
you will see that there is no code to check sub tree rules. It simply creates the event:

function createNotificationEvent( $objectID, $versionNum )
    {
        include_once( 'kernel/classes/notification/eznotificationevent.php' );
        $event =& eZNotificationEvent::create( 'ezpublish', array( 'object' => $objectID,
                                                                   'version' => $versionNum ) );
        $event->store();
    }

paul

Paul Borgermans

Friday 08 October 2004 6:35:31 am

Ah, I didn't look at the code, only what happens in a portal here ...

Tx for the clarification/correction :-)

-paul

eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans

Paul Forsyth

Friday 08 October 2004 6:45:10 am

We only noticed it because of the cron delays ;)

I've filed it as a bug:

http://ez.no/community/bug_reports/publish_creates_unnecessary_notification_event

paul

Hans Melis

Friday 08 October 2004 7:06:24 am

I think Paul B got it right for the most part. But I think the table is filled with events regardless of the fact if you have active subtree rules or not.

As Paul F pointed out, the publish code creates the entry in the table. And I think it's the cronjob that loops over those events and then checks if the event matches a notification rule.

I'm betting on "no bug, normal behaviour" ;)

Hans
http://blog.hansmelis.be

Paul Forsyth

Friday 08 October 2004 7:19:06 am

Probably ;)

At the very least i need to know if other parts of the system rely on this. So, if i remove it i wont get eZ weirdness later on...

paul

Marco Zinn

Friday 08 October 2004 7:42:33 am

Hi Folks,
i think, the events in that table are created on "publish", as mentioned.
They are cleared by the cronjob (notification part), when they are no longer needed.

There are also 2 other tables (something with "notification collection", i think), which handle the publish events for notification digests (i think, events are "moved" from the "event" to the "collection" tables, when they will be part of a digest).

For the initial question: I THINK, that you can empty the notificationevent table. We had the same issue with a large import and emptied that tables without having problems later.

But, a comment from the ezCrew should be more reliable.

Well, "do a backup", in any case ;)

Marco
http://www.hyperroad-design.com

Sergiy Pushchin

Tuesday 19 October 2004 3:31:29 am

If you do not have any notification set up, you can simply remove all entries from this table. It will not affect any other part of the system.
Back to the purpose of this table. It is general table for storing events happend in the system which can spawn sending of notification messages.