Well, it looks like this project dead-ended; I see nothing anywhere and I'm getting no response from posting.

So, I'm toying with this myself now, and I've hit a small design issue that I'd like an opinion on.

The xoopsnotifications table contains a column called not_itemid that is supposed to hold the key to a row in whatever table of whatever it is that you want to be notified about; a sort of dynamic-pseudo-foreign-key. It is defined as an UNSIGNED MEDIUMINT.

In this case, we want to hold a notification for a piCal event. The pical_event table has a key that is defined as an UNSIGNED INT AUTO_INCREMENT.

So, the issue is that the largest value xoopsnotifications.not_itemid can hold is 16,777,215 whereas the pical_event.id field can have a key as large as 4,294,967,295.

The issue exists right now; you have the ability to request notification of comments added to a given event and you have the ability to request notification of new events globally (though that doesn't seem to be working; I've subscribed to that and don't get notified when someone enters a new event). The notification of comments stores the pical_event.id value in xoopsnotifications.not_itemid.

I'd like an opinion on if I should degrade pical_event.id to UNSIGNED MEDIUMINT (seems the least risky), promote the xoopsnotifications.not_itemid to UNSIGNED INT (*SHOULD* be benign, but this *IS* a system table so it makes me nervous), or quit obsessing (not my nature ).

What do you think?

JP