Re: UMO interface functions

[sergey@total-knowledge.com]

Another argument: potentially custom UMO functionality may be implemented,
other types of UMO added or removed. If we have generic stored procedure,
no changes in C++ will be needed.

> I am not saying it shouldn't be designed explicitly. I'm saying it can be
> done inside of one stored procedure which gets child_UMO type and ID,
> parent_UMO type and ID as parameters.
> Otherwise we are going to have 20-30 attach/detach stored procedures
> instead of 2.
>
>> 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
>>
>>
>
>
>