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

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

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>:

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 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 <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