From: Denis S. Otkidach <ods@st...> - 2005-04-28 06:37:24
On Wed, 27 Apr 2005 22:54:57 +0000 Alexey Melchakov wrote:
AM> Commented out code is not functional in cases when items are linked
AM> to stream with (EXT_)FOREIGN_MULTISELECT fields, not with
AM> FOREIGN_DROP. Stream just have not field with apropiated convertToDB
AM> method. And virtual item is stored in, heh, "virtual", not
AM> configured field.
AM> + conds = 
AM> + for name in self.itemParamNames:
AM> + param = getattr(stream, name)
AM> + if stream.fields.has_key(name):
AM> + param = stream.fields[name].convertToDB(param,
AM> item)+ else:
AM> + param = param.id
AM> + conds.append(Query('%s=' % name, Param(param)))
AM> + return conn.join(conds)
I think field_type._retrieve_stream(item).fields.id.convertToDB will
work for both FOREIGN_DROP and [EXT_]FOREIGN_MULTISELECT field types.
Not sure is this is a right way to reach appropriate convertion method,
since _retrieve_stream is not part of public API. Without proper
convertion your code will break with string IDs containing non-ASCII
characters in unicode mode. We must find a way to reach convertion
method using public API (perhaps by extending it).
Denis S. Otkidach
From: Denis S. Otkidach <ods@st...> - 2005-04-28 07:06:11
On Thu, 28 Apr 2005 10:36:55 +0400 Denis S. Otkidach wrote:
DSO> Without proper convertion your code will break with string IDs
DSO> containing non-ASCII characters in unicode mode.
Actually even with ASCII-only (7-bit) IDs if the value for it is
converted to unicode as it is right now. That's why I've catched the
bug. I believe it must be corrected too: IDs should never be converted
to unicode, at least by default. That means STRING_ID shouldn't subclass
STRING, since they become quite different beasts. The question of
proper class name arises to avoid confusions.
Denis S. Otkidach