Re: UMO interface functions

["Alexey Parshin" <alexeyp@gmail.com>]

BTW, I have this crazy idea. We may have, actually, a single set of basic UMO tables ( _base, _content, _acl ), with the UMO type define in a field of the UMO. In that case, it is possible implementing ANY-2-ANY connections. The required stored proc code, in that case, is about 30% of currently required. However, if we go this way, the procs would have to understand every UMO type' limitations. That would require some properties table, enabling or disabling every possible action. The biggest advantage would be, of course, the ease of designing new UMO types.

2007/4/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com>:

Correct, we cannot attach everything to everything. Any potential linking
has to be designed explicitly.

Alexey Parshin wrote:
> I'm not sure if we can attach any UMO to any other UMO. For Instance -
> attaching a topic to an explanation, or attaching an explanation to
> problem doesn't make much sense to me.
> In the present structure of the database, we have only certain
> connections between UMOs allowed. If we need ANY-2-ANY type of
> connection - then we need a different DB structure.
>
> 2007/4/29, sergey@total-knowledge.com
> <mailto: sergey@total-knowledge.com> <sergey@total-knowledge.com
> <mailto:sergey@total-knowledge.com>>:
>
>     Regarding topic_attach_to_topic() and topic_detach_from_topic()
>     types of
>     stored procedures.
>     Since most of the UMOs(like problems, tests, dialogs, etc) can be
>     attached
>     to any other UMO except themself, imho it makes sense to have only 2
>     attach/detach stored procedures:
>     umo_attach() and umo_detach().
>     Attach should be performed only if child UMO is allowed to be
>     attched to
>     provided parent UMO.
>
>
>     > It's not going to work for every UMO. For example, problems have
>     more
>     > complicated functionality. Also course is much different from
>     others.
>     >
>     >> Hello,
>     >>
>     >> It looks like we have to standardize the set of the UMO
>     functions. Here
>     >> is
>     >> the typical list that is implemented for topic_list,
>     topic_explanation,
>     >> and
>     >> dialog_of_texts:
>     >>
>     >> GRANT EXECUTE ON FUNCTION <UMO>_create(int,varchar(80),text) TO
>     PUBLIC;
>     >> GRANT EXECUTE ON FUNCTION <UMO>_delete(int) TO PUBLIC;
>     >> GRANT EXECUTE ON FUNCTION <UMO>_create_version(int) TO PUBLIC;
>     >> GRANT EXECUTE ON FUNCTION <UMO>_publish_version(int) TO PUBLIC;
>     >> GRANT EXECUTE ON FUNCTION
>     <UMO>_add_content(int,int,varchar(80),text) TO
>     >> PUBLIC;
>     >> GRANT EXECUTE ON FUNCTION
>     <UMO>_modify_content(int,int,varchar(80),text)
>     >> TO
>     >> PUBLIC;
>     >> GRANT EXECUTE ON FUNCTION <UMO>_delete_content(int) TO PUBLIC;
>     >> GRANT EXECUTE ON FUNCTION <UMO>_attach_to_<parent
>     >> UMO>(int,int,int,int,int)
>     >> TO PUBLIC;
>     >> GRANT EXECUTE ON FUNCTION <UMO>_detach_from_<parent
>     UMO>(int,int) TO
>     >> PUBLIC;
>     >>
>     >> Please, notice: In order to match this standard I had to modify
>     names of
>     >> few
>     >> topic_* functions, related to content and attach/detach.
>     >>
>     >> --
>     >> Alexey Parshin,
>     >> http://www.sptk.net
>     >>
>     >
>     >
>     >
>
>
>
>
>
> --
> Alexey Parshin,
> http://www.sptk.net

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

-- 
Alexey Parshin,
http://www.sptk.net