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

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

I wouldn't worry about it too much. Any object should be identified by ID. This is the basic requirement. The ID itself is meaningless, but it allows to avoid any problems with object identification.
BTW,  I don't see how identifying a content with topic ID and language is less exposing than identifying it with content ID.

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

I guess your way is just as fine, since you will be able to get hold of
topic ID
from your topic_content ID for verification purposes..
Thing that bothers me slightly (only slightly at this point), is that we
are essentially
exposing internal DB structure to the UI layer, instead of abstracting
it to some
degree with stored procedures..

Alexey Parshin wrote:
> 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
> <mailto: 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 >
>     > <mailto: 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>
>     <mailto: 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 >
>     >     <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>>>:
>     >     >>
>     >     >>> 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

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

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