Re: Latest DB schema

["Ilya A. Volynets-Evenbakh" <ilya@total-knowledge.com>]

OK. This looks very good to me. Even better then what I had originally
in mind
(Per-object notifications, that would be sent to all authors in case of
referenced
object change). Per-object per-user preferences are certainly better!

Now, another thing that Sergey brought up, and which wasn't answered yet:

>> Also how do we know if a problem was "solved"/"not yet solved" by student?
>>
>>
> Now, this is very good question. Belkman?


Alexey Parshin wrote:
> I have added a preliminary notifications support. The current version
> has simplified data integrity since (at this moment) I believe this
> data is not that important to add and maintain around 6 extra tables.
>
> In short words, we have notification_list table that has the following
> fields (besides nl_id):
>
> nl_person (int) - a reference to the notification receiver
> person_list( pl_id );
> nl_even_type (int) - a bit-mask of events that trigger a notification.
> See event_type( et_value ) for possible events.
> nl_object_type (int) - a reference to the object type user_object_type
> ( uot_id );
> nl_object_id (int) - a reference to the object id (not covered by the
> foreign key). Object id is an id of the object record in corresponding
> *_base table for this object type. For example, for topic objects it
> would be topic_base table.
>
> This schema allows to define a set of events for the particular
> object, that should trigger notification for the particular user.
> Since nl_object_id refers to an object and not to an object version,
> all versions of the object are included.
>
> 2006/11/1, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto:ilya@total-knowledge.com>>:
>
>     Alexey Parshin wrote:
>     > IMO, any preferences that are not one-to-many (ie not a list), like
>     > preferred_language, may go into person_list.
>     I tend to agree with that.
>     > As for the others - we would need to discuss it separately,
>     since it
>     > probably requires support on the database level.
>     > The notifications, for instance, belong to an object.
>     Hmm... At first I wanted to say "to object relationship", but then
>     realized that relationships themselves
>     are versioned. At the same time each object-object relationship
>     may have
>     its own notification preference.
>     I guess this either means separate object<->object table for
>     notification statuses, or copying that
>     preference when creating new object version, and using last
>     version when
>     sending out actual
>     notifications.
>     >
>     > 2006/10/31, sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com>
>     > <mailto:sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com>> < sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com>
>     > <mailto: sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com>>>:
>     >
>     >     > sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com>
>     <mailto:sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com>>
>     >     wrote:
>     >     >> I think we may need something like person_preferences
>     table to
>     >     handle
>     >     >> user
>     >     >> preferences for
>     >     >>
>     >     >> 1. Prefered UI language.
>     >     >>
>     >     > Good point. Although this might be just a field in person_list
>     >
>     >     IMO a new table may be better, since user may have many
>     additional
>     >     preferncies(email notifications for ordering, currency, the
>     way UI
>     >     displays certain UMOs/features, any kind of
>     >     restrictions/limitations/preferencies for UMO he is an
>     author of,
>     >     etc).
>     >
>     >
>     >     >> 2. Object change notifications/preferencies.
>     >     >>
>     >     > No, these are per-object-relation. Although you are right
>     in that
>     >     > the info is missing.
>     >     >> Also we need to handle user types somehow, probably using
>     >     user_types
>     >     >> table.
>     >     >>
>     >     > There are no user-types as such. There are access kinds users
>     >     > have to different objects. ACL tables handle that.
>     >     >
>     >     > --
>     >     > Ilya A. Volynets-Evenbakh
>     >     > Total Knowledge. CTO
>     >     > http://www.total-knowledge.com
>     >     >
>     >     >
>     >
>     >
>     >
>     >
>     >
>     > --
>     > Alexey Parshin,
>     > http://www.sptk.net <http://www.sptk.net>
>
>     --
>     Ilya A. Volynets-Evenbakh
>     Total Knowledge. CTO
>     http://www.total-knowledge.com
>
>
>
>
> -- 
> Alexey Parshin,
> http://www.sptk.net 

-- 
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com