On Thu, Mar 15, 2018 at 3:13 AM, Dave Page <dp...@pgadmin.org> wrote:
> Hi
>
> On Tue, Mar 13, 2018 at 11:18 PM, Khushboo Vashi <
> khushboo.va...@enterprisedb.com> wrote:
>
>>
>>
>> On Wed, Mar 14, 2018 at 2:18 AM, Dave Page <dp...@pgadmin.org> wrote:
>>
>>>
>>>
>>> On Tue, Mar 13, 2018 at 12:46 AM, Khushboo Vashi <
>>> khushboo.va...@enterprisedb.com> wrote:
>>>
>>>>
>>>>
>>>> On Tue, Mar 13, 2018 at 9:39 AM, Dave Page <dp...@pgadmin.org> wrote:
>>>>
>>>>>
>>>>>
>>>>> On 12 Mar 2018, at 23:12, Khushboo Vashi <
>>>>> khushboo.va...@enterprisedb.com> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Mar 13, 2018 at 2:29 AM, Dave Page <dp...@pgadmin.org> wrote:
>>>>>
>>>>>> So I was trying to test this, and every time I try to run a backup,
>>>>>> I'm getting the following, with or without your patch:
>>>>>>
>>>>>> (sqlite3.ProgrammingError) You must not use 8-bit bytestrings unless
>>>>>> you use a text_factory that can interpret 8-bit bytestrings (like
>>>>>> text_factory = str). It is highly recommended that you instead just
>>>>>> switch
>>>>>> your application to Unicode strings. [SQL: u'INSERT INTO process (pid,
>>>>>> user_id, command, "desc", arguments, logdir, start_time, end_time,
>>>>>> exit_code, acknowledge) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?)']
>>>>>> [parameters: (180312205250107339, 1,
>>>>>> u'/Library/PostgreSQL/9.4/bin/pg_dump',
>>>>>> 'ccopy_reg\n_reconstructor\np0\n(cpgadmin.tools.backup\nBack
>>>>>> upMessage\np1\nc__builtin__\nobject\np2\nNtp3\nRp4\n(dp5\nS\'cmd\'\np6\nV
>>>>>> --file "/Users/dpage/foo.dmp" --host "127.0.0.1" --port "5432" --username
>>>>>> "postgres" --no-password --verbose --format=c --blobs
>>>>>> "\xe9"\np7\nsS\'backup_type\'\np8\nI3\nsS\'database\'\np9\nV
>>>>>> \xe9\np10\nsS\'bfile\'\np11\nS\'foo.dmp\'\np12\nsS\'sid\'\np13\nI1\nsb.',
>>>>>> u'--file,/Users/dpage/foo.dmp,--host,127.0.0.1,--port,5432,-
>>>>>> -username,postgres,--no-password,--verbose,--format=c,--blobs,\xe9',
>>>>>> '/var/lib/pgadmin/sessions/process_logs/180312205250107339', None,
>>>>>> None, None, None)]
>>>>>>
>>>>>> Any thoughts as to what's going on? I wasn't getting this on my other
>>>>>> laptop, and I can't think what else we would have changed to cause this.
>>>>>>
>>>>>> Deleting all the records from the process table from SQLITE will
>>>>> solve this problem.
>>>>> There were few issues related to encoding-decoding in my old patches,
>>>>> you may have applied those.
>>>>>
>>>>>
>>>>> I deleted the database entirely, and still saw the problem.
>>>>>
>>>>> I have tried many things to reproduce this but couldn't. I faced this
>>>> issue when I was fixing the issue but not now.
>>>> Please make sure to delete the old session and a process table (or
>>>> database) and apply my latest patch. (of course you do this :) )
>>>> I have PY - 2.7.12, psycopg2 - 2.7.4 and SQLAlhemy -1.0.14 to be more
>>>> specific.
>>>>
>>>>>
>>> Well I eventually got this to work (basically recreated most of my dev
>>> environment), so I committed the patch as it's clearly an improvement.
>>>
>>> Thanks.
>>
>>> I can still reproduce the display issue I mentioned though - see the
>>> attached screenshot which shows é in a couple of places. I wonder if
>>> it's because the database name is just a single character in my tests,
>>> whilst you had some other unicode characters in the string?
>>>
>>> I have tested it with a single character also but couldn't reproduce
>> this. Please find the attached screen-shot for the same.
>> Can you please take a complete screen shot of the screen (with left side
>> tree and properties panel of the database) and send it?
>>
>
> Sure - attached.
>
>
I didn't find any root cause as the below line responsible for un-escaping
the html and it is clearly shown that it is not happening in your case.
$header.find('.bg-detailed-desc').html(_.unescape(self.detailed_desc));
> --
> Dave Page
> Blog: http://pgsnake.blogspot.com
> Twitter: @pgsnake
>
> EnterpriseDB UK: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
