UniverseUniversity


Home Projects Jobs Clientele Contact

uu


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

Re: UMO interface functions



Hmm. Not all the referential integrity. Actually, the integrity would work just fine. Any of the UMO basic tables would use just the same connections as before.
The only problem would be to explain to the database that objects should sometimes behave the different way. For instance, a topic may be a parent to certain other UMOs, but (in current implementation) an explanation may not, or that Texts In Dialog may refer to each other.

I'm not insisting on implementing it, but would you give it mor thought, please?

2007/4/29, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com >:
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




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

Authoright © Total Knowledge: 2001-2008