|
Author
|
Message
|
|
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.
|
