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 <firstname.lastname@example.org
> <mailto: email@example.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 ;-)
> firstname.lastname@example.org <mailto:email@example.com> wrote:
> > Here is the part of our discussion on IRC regarding returning 2
> > from stored procedure issue:
> > HappySquirrel> sergey, I was trying to implement your idea about
> > 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, firstname.lastname@example.org
> <mailto: email@example.com> <firstname.lastname@example.org
> >>> 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
> Alexey Parshin,
Ilya A. Volynets-Evenbakh
Total Knowledge. CTO
Authoright © Total Knowledge: 2001-2008