Re: Implementing "Create Topic" [was: Identical UMO titles in UU]

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

It is fine. I just suggest that no edit operations should use data to find and update a record.

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

While you are absolutely right about having the id internally aspect,
you will still have to get same info - in order to verify access, make sure
the object is currently editable, if we are changing the main language, etc.


Alexey Parshin wrote:
> I believe that any object we can edit must have a unique ID (primary
> key). Searching by a combination of parameters is a) longer b) may
> give zero or several records (in general case).
> While in this particular case it will work, it's still a bad
> programming technic. In any case, any object on the screen must have a
> hidden ID attached to it. This also assumes, that any edit or update
> operation must receive an editing object id.
>
> 2007/4/26, Ilya A. Volynets-Evenbakh <ilya@total-knowledge.com
> <mailto: ilya@total-knowledge.com>>:
>
>     topic_content stuff was intended for translations. This means, that
>     under no conditions
>     should UI be concerned with IDs from that table. Instead, the way to
>     deal with it will be
>     through topic_id+language combinations (which is, incidentally, how
>     access control to
>     translations should work). Let's have Belkman and Sergey think through
>     the whole
>     process in detail, and send proposal here, before trying to implement
>     this again, so that
>     we don't have to re-do it ;-)
>
>     sergey@total-knowledge.com <mailto:sergey@total-knowledge.com> wrote:
>     > Here is the part of our discussion on IRC regarding returning 2
>     values
>     > from stored procedure issue:
>     >
>     > HappySquirrel> sergey, I was trying to implement your idea about
>     returning
>     > more than one value from topic_create
>     > <HappySquirrel> At this moment, I don't think it's a good idea
>     > <HappySquirrel> 1) It instantly breaks any code using topic_create()
>     > <HappySquirrel> 2) It makes it harder to work with
>     topic_create(), and
>     > makes it an exception of everything else we have
>     > <HappySquirrel> I admit, though, that my workaround isn't perfect
>     > <HappySquirrel> (that is - to call a select after topic_create()).
>     > <HappySquirrel> however, I can make a special proc,
>     > <HappySquirrel> topic_create_ext(), that would do it for you
>     > <HappySquirrel> (if you insist)
>     >
>     > My concern is that we are going to have the same issue at the
>     creation of
>     > every UMO in the application - we'll need UMO_id and
>     UMO_content_id every
>     > time, so I'd like to ask everyone's opinion on this subject.
>     >
>     >
>     >
>     >> It is possible to return a structure from stored proc.
>     Unfortunately, ODBC
>     >> has no support for this. I'd try to return two values, but it
>     would take
>     >> some time.
>     >>
>     >> 2007/4/25, sergey@total-knowledge.com
>     <mailto: sergey@total-knowledge.com> <sergey@total-knowledge.com
>     <mailto:sergey@total-knowledge.com>>:
>     >>
>     >>> When I modify topic I have to deal with topic_content_id, so I
>     need to
>     >>> get
>     >>> this value on topic creation.
>     >>> Currently my Topic::create() returns topic_id(b/c
>     topic_create() returns
>     >>> topic_id). I'd like to avoid running the additional query to get
>     >>> topic_content_id by topic_id.
>     >>> Is it possible to return structures from stored procedure? Any
>     ideas how
>     >>> I
>     >>> should deal with this?
>     >>>
>     >>>
>     >>>
>     >> --
>     >> 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