[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
Re: UMO interface functions
This will mean we'll need to do _all_ of the referential integrity
manually, plus whole horde of other things that database already
does for us. Not to mention pain of doing efficient indexes etc..
Let's just use one flat file with all data stored in there instead.
Alexey Parshin wrote:
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
<mailto: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>
> <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>>>:
>
> 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
--
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
http://www.total-knowledge.com