FileStorage error if user contains non-ascii characters

The ITransaction interface says

    user = zope.interface.Attribute(
        """A user name associated with the transaction.

        The format of the user name is defined by the application. The value
        is of Python type str. Storages record the user value, as meta-data,
        when a transaction commits...

that user is of type str. So the FileStorage implementation is correct in this sense. But I don't understand why it cannot be unicode.

If there is a reason, then re-target this bug to zope.app.publication that should encode the principal id.

Perhaps it would be nice if the user field was unicode. <shrug> The
definition of this interface predates unicode in Python. This is
unlikely to change.

A more likely change is to drop these fields altogether and keep just
the extension data, which allows any picklable data.

I suggest changing zope.app.publication to store the user as extension
data.

BTW, while talking about transaction meta data, it would be nice if
zope.app.publication also recorded the host name and pid. :)

On Thursday, September 23, 2010, Jim Fulton wrote:
> Perhaps it would be nice if the user field was unicode. <shrug> The
> definition of this interface predates unicode in Python. This is
> unlikely to change.
>
> A more likely change is to drop these fields altogether and keep just
> the extension data, which allows any picklable data.

What about simply using UTF-8 in zope.app.publication to encode and decode the
principal id. This would require the smallest code change.

Regards,
Stephan
--
Entrepreneur and Software Geek
Google me. "Zope Stephan Richter"

On Thu, Sep 23, 2010 at 10:20 AM, Stephan Richter
<email address hidden> wrote:
> On Thursday, September 23, 2010, Jim Fulton wrote:
>> Perhaps it would be nice if the user field was unicode. <shrug> The
>> definition of this interface predates unicode in Python.  This is
>> unlikely to change.
>>
>> A more likely change is to drop these fields altogether and keep just
>> the extension data, which allows any picklable data.
>
> What about simply using UTF-8 in zope.app.publication to encode and decode the
> principal id. This would require the smallest code change.

I doubt it would be much smaller than:

   t.setUser(u) -> t.setExtendedInfo('user', u)

IIRC the publisher already uses extended info for the description/url.

Jim

--
Jim Fulton

On Thursday, September 23, 2010, Jim Fulton wrote:
> I doubt it would be much smaller than:
>
> t.setUser(u) -> t.setExtendedInfo('user', u)
>
> IIRC the publisher already uses extended info for the description/url.

But wouldn't you have to potentially change code that depends on the user
being set in the user field? I think that's the real cost/risk.

Regards,
Stephan
--
Entrepreneur and Software Geek
Google me. "Zope Stephan Richter"

On Thu, Sep 23, 2010 at 10:51 AM, Stephan Richter
<email address hidden> wrote:
> On Thursday, September 23, 2010, Jim Fulton wrote:
>> I doubt it would be much smaller than:
>>
>>    t.setUser(u) -> t.setExtendedInfo('user', u)
>>
>> IIRC the publisher already uses extended info for the description/url.
>
> But wouldn't you have to potentially change code that depends on the user
> being set in the user field?

Sure. Is there any code like that? The only code I can think of
would be zope 2's undo mechanism and zope 2 doesn't use
zope.app.publisher.

Jim

--
Jim Fulton

zodbbrowser uses IStorageUndoable's undoLog() which returns a list of dicts, and t.user is in those dicts as txn_info['user_name']. That would be easy to change.

For backwards compatibility why not use both?

   t.setUser(u.encode('UTF-8', 'replace')) # must be str
   t.setExtendedInfo('user', u) # unicode version