If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-02-17
Logged In: YES
user_id=1141133
It may be that your ODB contains the non-functional version
of extensions.odbc.data.dll.rFork. I've attached a
functional version of extensions.odbc.data.dll for your testing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When coercing a list to a string, individual list items are
limited to 255 chars, including the enclosing quotes and
ellipsis if the list item needs to be truncated.
This is handled by listtostring() in langlist.c.
If we remove the 255 char limit, we have to be extremely
careful about unintended side-effects. For example, string
representations of lists obtained for display purposes
should probably continue to use the truncated form,
otherwise navigating lists in the value columns of tables
could become even more impractical.
If you need a work-around for cvsSync, I think switching to
base64-encoded packed values for lists and records may be
the way to go for now. Is that feasible?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-02-17
Logged In: YES
user_id=1141133
I've already done a workaround for cvsSync! :-) I don't
encode all lists and records but they can be force encoded
for troublesome items.
For display in tables a truncated version makes sense. But
if I start to edit it, would be nice if I were able to edit
the real representation. The cost of on the fly conversion
may be too high. As a workaround for this, let me convert
it to a wp or outline and be able to edit the full
representaton.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Anonymous
-
2006-02-17
priority: 7 --> 5
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to have a better editor for lists and records as
well, but that's a different issue.
The 255 char limit only seems to affect list-to-string
conversion. Apparently, the limit was already removed from
string-to-list oncversion.
I think the way to go is to rewrite listtostring using a
handlestream and adding a boolean param, indicating whether
to abbreviate list items or not. Once that's implemented, we
can slowly enable the full representation for selected callers.
If anybody wants to give this a try, please assign the bug
to yourself. (I might do so this weekend.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
extensions.odbc.data.dll
Logged In: YES
user_id=1141133
It may be that your ODB contains the non-functional version
of extensions.odbc.data.dll.rFork. I've attached a
functional version of extensions.odbc.data.dll for your testing.
Logged In: YES
user_id=1137587
When coercing a list to a string, individual list items are
limited to 255 chars, including the enclosing quotes and
ellipsis if the list item needs to be truncated.
This is handled by listtostring() in langlist.c.
If we remove the 255 char limit, we have to be extremely
careful about unintended side-effects. For example, string
representations of lists obtained for display purposes
should probably continue to use the truncated form,
otherwise navigating lists in the value columns of tables
could become even more impractical.
If you need a work-around for cvsSync, I think switching to
base64-encoded packed values for lists and records may be
the way to go for now. Is that feasible?
Logged In: YES
user_id=1141133
I've already done a workaround for cvsSync! :-) I don't
encode all lists and records but they can be force encoded
for troublesome items.
For display in tables a truncated version makes sense. But
if I start to edit it, would be nice if I were able to edit
the real representation. The cost of on the fly conversion
may be too high. As a workaround for this, let me convert
it to a wp or outline and be able to edit the full
representaton.
Logged In: YES
user_id=1137587
I'd like to have a better editor for lists and records as
well, but that's a different issue.
The 255 char limit only seems to affect list-to-string
conversion. Apparently, the limit was already removed from
string-to-list oncversion.
I think the way to go is to rewrite listtostring using a
handlestream and adding a boolean param, indicating whether
to abbreviate list items or not. Once that's implemented, we
can slowly enable the full representation for selected callers.
If anybody wants to give this a try, please assign the bug
to yourself. (I might do so this weekend.)