UniverseUniversity


Home Projects Jobs Clientele Contact

uu

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UMO interface functions

You can very easily implement this kind of abstraction in C++.
I.E. you could have a base class that has more or less generalized
function for calling _attach stored procedures, and then derived classes
would have functions providing changing parts of the SQL.

sergey@total-knowledge.com wrote:

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









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

Authoright © Total Knowledge: 2001-2008