Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hdbIx-00016V-R7 for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Jun 2019 14:11:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1hdbIw-0004DS-Iu for pgadmin-hackers@arkaria.postgresql.org; Wed, 19 Jun 2019 14:11:14 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hdbIw-00046G-3Z for pgadmin-hackers@lists.postgresql.org; Wed, 19 Jun 2019 14:11:14 +0000 Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1hdbIp-0002U1-2n for pgadmin-hackers@postgresql.org; Wed, 19 Jun 2019 14:11:13 +0000 Received: by mail-wr1-x42e.google.com with SMTP id m3so3597853wrv.2 for ; Wed, 19 Jun 2019 07:11:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pgadmin.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XEtlqesYJtajfQGWK6kSWx4bMMdJHP8AS7Q9RtpkLoU=; b=D8Nvf1ifYWLcOkmQ6gVcbJaRpSLbhiziYc0ZRBFVRH4Jn2qYkA7m96sJmU+qnlewc+ jr8HyNGzxaPAMcKD4IaNO9BgS0qnOAZa/vgs3goEpf9+XDWs2fH4fs9fxrwjZmq6yeX4 cNF35XjXUjnqW7NffjQNa3nOF3gTy51WkHpDJiXk68vKR9LgttkfTOACb2CTd7SlRQv9 8kLCe9yR2tw5MUePyxYK5WR73aIi+gDVXZG+66vhxf+yXfdfxNjh3HVdouXaNrxmccPX AIHva4awoDu078zqfrmOAA1zQFvNF57z1e6lJVBIyfMxJzMBx5sUcbq+LXbmrSAE9nGI DN2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XEtlqesYJtajfQGWK6kSWx4bMMdJHP8AS7Q9RtpkLoU=; b=DJ0pUxEaD96j74/uTgEqFkFe9CvG6vP4+WPoS0nwGxCFPUcXvYDtPVKf54W8CTpyd5 dGEZGAy012OPL5yZmn0T34vZvqCTIv6Muhv+TZMzZqkFz08o/45UpeKJQBAPKHwieSwE O6c+/+V7yTef6/zRd6W+THpu3+vX3IfLgmHuxiysbhi1Sn6buit7qxGxGZdBzS2x9wpC utFSd5zUNmdBJuNQQU4W6GtqcdRmb1pyh4OQePCaf5gfgqBByjPahfPnnYIsVBN+LgrW 5fPYlugi6U8rrvW2su50u5oHhBuafiAG7nxWOhOWnzyRqHXn5ACuJvC2uhKYoilPMR3O 6K/A== X-Gm-Message-State: APjAAAXxBjgCoKJU4i0NUVgobtgSOb30DHYKJc7lFurkRiBg9w+4vShs FdsbaGTQATiBSXVfKCQaLQLhb2PowF+PEBsoLwWi9g== X-Google-Smtp-Source: APXvYqyvfhkkwwLAlqHDMUTlDE3nyKxpUwoR95ox5FNHQhYJ/hayZCayBr7LjHxOi65xdFMkpLr9UBbtzVUu6FkZFFs= X-Received: by 2002:a05:6000:106:: with SMTP id o6mr9878473wrx.4.1560953464545; Wed, 19 Jun 2019 07:11:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Dave Page Date: Wed, 19 Jun 2019 15:10:51 +0100 Message-ID: Subject: Re: [GSoC][Patch] Automatic Mode Detection V1 To: Yosry Muhammad Cc: pgadmin-hackers Content-Type: multipart/mixed; boundary="000000000000c459e3058badcc5a" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk --000000000000c459e3058badcc5a Content-Type: multipart/alternative; boundary="000000000000c459e1058badcc58" --000000000000c459e1058badcc58 Content-Type: text/plain; charset="UTF-8" Hi On Wed, Jun 19, 2019 at 2:47 PM Yosry Muhammad wrote: > Hi, > > > On Wed, Jun 19, 2019, 1:54 PM Dave Page wrote: > . > > - We need to add a "do you want to continue" warning before actions like > Execute or EXPLAIN are run, if there are unsaved changes in the grid. > > - I think we should make the text in any cells that has been edited bold > until saved, so the user can see where changes have been made (as they can > with deleted rows). > > > Both done, new rows are highlighted too. > > > Nice! I realise it's most likely not your code, but if you can fix the > wrapping so it doesn't break mid-word, that would be good. See the attached > screenshot to see what I mean. > > > > Will do. > > > - If I make two data edits and then delete a row, I get 3 entries in the > History panel, all showing the same delete. I would actually argue that > data edit queries that pgAdmin generates should not go into the History at > all, but maybe they should be added albeit with a flag to say they're > internal queries and an option to hide them. Thoughts? > > > That was a bug with the existing 'save changes' action of 'View Data', on > which mine is based upon. I fixed the bug, now the queries are shown > correctly. However, the queries are shown in the form in which they are > sent from the backend to the database driver (without parameters - also an > already existing bug in View Data Mode), for example: > > INSERT INTO public.kweek ( > media_url, username, text, created_at) VALUES ( > %(media_url)s::character varying, %(username)s::character varying, > %(text)s::text, %(created_at)s::timestamp without time zone) > returning id; > > > I propose two solutions: > 1- Hide pgadmin's generated sql from history (in both modes). > 2- Show the actual sql query that was executed after the parameters are > plugged in (more understandable and potentially helpful). > > > I like the idea of doing 2 - but I think we should have a checkbox on the > history panel to show/hide generated queries (and we should include > transaction control - BEGIN, COMMIT etc - in the generated query class). > > > > I can work on option 2 now and then work on > the checkbox if/when there is time. > I'm pretty sure there will be time :-) > > > > - We need to think about how data editing fits in with transaction > control. Right now, it seems to happen entirely outside of it - for > example, I tend to work with auto commit turned off, so my connection sits > idle-in-transaction following an initial select, and remains un-affected by > edits. Please think about this and suggest options for us to discuss. > > > I integrated the data editing in the transaction control as you noted. Now > the behavior is as follows: > 1- In View Data mode, same existing behavior. > 2- In Query Tool mode: > - If auto-commit is on: the modifications are made and commited once save > is pressed. > - If auto-commit is off: the modifications are made as part of the ongoing > transaction (or a new one if no transaction is ongoing), they are not > commited unless the user executes a commit command (or rollback). > > > That seems to work. I think we need to make it more obvious that there's a > transaction in progress - especially as that can be the case after the user > hits the Save button and thinks their data is safe (a side-thought is that > perhaps we shouldn't require the Save button to be pressed when auto-commit > is turned off, as that's just odd). We should highlight the transaction > state more clearly to the user, and make sure we prompt for confirmation if > they try to close the tab or the whole window. > > > The transaction status can be made more obvious and point out when a > transaction is in progress that changes aren't commited. However, removing > the save button when auto commit is off will cause us to a send a request > and execute a query every time any cell is changed (which can be by > accident or some kind of draft). I also think it will make more sense when > there is a dedicated button, which can be named such that it is clear that > it only executes some queries. Also, the pop up that shows after edits are > succeesful can also state thar these changes are not yet commited. > Yeah, I agree removing the button for some modes only is weird. Maybe adding info to the notification, and having a more prominent "Your transaction is still in progress" notification will be enough. Another thought - we also need to figure out what happens if the user edits data in the grid and when saving, an error occurs (e.g. trying to insert null into a not-null field). How does that tie into transaction control? For example, auto-rollback may then revert other changes made via SQL (which should have been atomic, with the data changes) - or having auto-rollback turned off may then require the user to explicitly start a new transaction before attempting to save the data again. Perhaps we need to precede data changes with a savepoint, and then roll back to that if there's an error? > > I think it makes more sense for filters to be disabled. I mean since the > user is already writing SQL it would be more convenient to just edit it > directly. > > > Well we're not going to just disable them - we'll either remove them, or > try to make them work. I'm leaning strongly towards just removing that code > entirely. > > > I meant disabling them in the query tool while keeping them in the View > Data mode as the user cannot edit the sql in the View Data mode. Do you > want to remove the feature from both modes completely? > > > I think you misunderstand - I want to remove the View Data mode entirely. > Your work should replace it. > > > As a user of pgAdmin I think this might not be the best option. Not all > users of pgAdmin are developers or know SQL. I worked on several projects > before where other people on the team (or frontend developers) would just > want to take a look at some data or do simple edits using the GUI. Also, > other management studios for other DBMSs also allow for this. In addition, > the user can do sorting of data without knowing SQL. What I think can be > done (potentially - maybe in the future) is limit the dependance on SQL > knowledge when doing filters in View Data mode, while disabling filters and > so in the Query Tool. > Hmm, the point of this project (which has been a goal for maybe 20 years!) was to remove that mode entirely. There is an argument that users can use the "SELECT Script" option instead if they don't know SQL, but that would still require the Sort/Filter options. What do other folks think? Oh, and icon attached! -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company --000000000000c459e1058badcc58 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi

On Wed, Jun 19, 2019 at 2:47 PM Yosry Muhammad <= yosrym93@gmail.com> wrote:
=
<= span style=3D"font-family:sans-serif;font-size:12.8px">Hi,

=
On Wed, Jun 19, 2019, 1:54 PM Dave Page <dpage@pgadmin.org> wrote:
.
- We need to add a "do you want to continue" wa= rning before actions like Execute or EXPLAIN are run, if there are unsaved = changes in the grid.

- I think we should make the = text in any cells that has been edited bold until saved, so the user can se= e where changes have been made (as they can with deleted rows).
=

Both done, new rows are highlighted = too.=C2=A0

Nice= ! I realise it's most likely not your code, but if you can fix the wrap= ping so it doesn't break mid-word, that would be good. See the attached= screenshot to see what I mean.
=C2=A0

Will do.
=

- If I make two data edits and then = delete a row, I get 3 entries in the History panel, all showing the same de= lete. I would actually argue that data edit queries that pgAdmin generates = should not go into the History at all, but maybe they should be added albei= t with a flag to say they're internal queries and an option to hide the= m. Thoughts?

That was a b= ug with the existing 'save changes' action of 'View Data', = on which mine is based upon. I fixed the bug, now the queries are shown cor= rectly. However, the queries are shown in the form in which they are sent f= rom the backend to the database driver (without parameters - also an alread= y existing bug in View Data Mode), for example:

INSERT INTO publi= c.kweek (
media_url, username, text, created_at) VALUES (
%(media_url= )s::character varying, %(username)s::character varying, %(text)s::text, %(c= reated_at)s::timestamp without time zone)
=C2=A0returning id;
=C2=A0
I propose two solutions:
1- Hide pg= admin's generated sql from history (in both modes).
2- Show t= he actual sql query that was executed after the parameters are plugged in (= more understandable and potentially helpful).

I like the idea of doing 2 - but I thi= nk we should have a checkbox on the history panel to show/hide generated qu= eries (and we should include transaction control - BEGIN, COMMIT etc - in t= he generated query class).
=C2=A0
<= /div>

I can work on option 2 now and then work on= =C2=A0
the checkbox if/when there is time.

<= /div>
I'm pretty sure there will be time :-)
=C2=A0
=
<= div dir=3D"auto">
=


- We need to think about how data editing fits in with transaction= control. Right now, it seems to happen entirely outside of it - for exampl= e, I tend to work with auto commit turned off, so my connection sits idle-i= n-transaction following an initial select, and remains un-affected by edits= . Please think about this and suggest options for us to discuss.

I integrated the data editing in th= e transaction control as you noted. Now the behavior is as follows:
1- In View Data mode, same existing behavior.
2- In Query = Tool mode:
- If auto-commit is on: the modifications are made and= commited once save is pressed.
- If auto-commit is off: the modi= fications are made as part of the ongoing transaction (or a new one if no t= ransaction is ongoing), they are not commited unless the user executes a co= mmit command (or rollback).
That seems to work. I think we need to make it more obvious th= at there's a transaction in progress - especially as that can be the ca= se after the user hits the Save button and thinks their data is safe (a sid= e-thought is that perhaps we shouldn't require the Save button to be pr= essed when auto-commit is turned off, as that's just odd). We should hi= ghlight the transaction state more clearly to the user, and make sure we pr= ompt for confirmation if they try to close the tab or the whole window.

The transaction= status can be made more obvious and point out when a transaction is in pro= gress that changes aren't commited. However, removing the save button w= hen auto commit is off will cause us to a send a request and execute a quer= y every time any cell is changed (which can be by accident or some kind of = draft). I also think it will make more sense when there is a dedicated butt= on, which can be named such that it is clear that it only executes some que= ries. Also, the pop up that shows after edits are succeesful can also state= thar these changes are not yet commited.

=
Yeah, I agree removing the button for some modes only is weird. = Maybe adding info to the notification, and having a more prominent "Yo= ur transaction is still in progress" notification will be enough.

Another thought - we also need to figure out what happ= ens if the user edits data in the grid and when saving, an error occurs (e.= g. trying to insert null into a not-null field). How does that tie into tra= nsaction control? For example, auto-rollback may then revert other changes = made via SQL (which should have been atomic, with the data changes) - or ha= ving auto-rollback turned off may then require the user to explicitly start= a new transaction before attempting to save the data again. Perhaps we nee= d to precede data changes with a savepoint, and then roll back to that if t= here's an error?
=C2=A0

I think it makes more sense for filters to be disa= bled. I mean since the user is already writing SQL it would be more conveni= ent to just edit it directly.

=
Well we're not going to just disable them - we'll either remov= e them, or try to make them work. I'm leaning strongly towards just rem= oving that code entirely.

=C2=A0
I meant disabling them in the query tool while keeping th= em in the View Data mode as the user cannot edit the sql in the View Data m= ode. Do you want to remove the feature from both modes completely?

I think you misundersta= nd - I want to remove the View Data mode entirely. Your work should replace= it.

<= /div>
As a user of pgAdmin I think this might not be the best option. Not all= users of pgAdmin are developers or know SQL. I worked on several projects = before where other people on the team (or frontend developers) would just w= ant to take a look at some data or do simple edits using the GUI. Also, oth= er management studios for other DBMSs also allow for this. In addition, the= user can do sorting of data without knowing SQL. What I think can be done = (potentially - maybe in the future) is limit the dependance on SQL knowledg= e when doing filters in View Data mode, while disabling filters and so in t= he Query Tool.

Hmm, the point o= f this project (which has been a goal for maybe 20 years!) was to remove th= at mode entirely. There is an argument that users can use the "SELECT = Script" option instead if they don't know SQL, but that would stil= l require the Sort/Filter options.=C2=A0

= What do other folks think?

Oh, and icon attached!<= /div>

--
Dave = Page
Blog: htt= p://pgsnake.blogspot.com
Twitter: @pgsnake

EnterpriseDB UK: <= a href=3D"http://www.enterprisedb.com" target=3D"_blank">http://www.enterpr= isedb.com
The Enterprise PostgreSQL Company
--000000000000c459e1058badcc58-- --000000000000c459e3058badcc5a Content-Type: image/svg+xml; name="save_data_changes.svg" Content-Disposition: attachment; filename="save_data_changes.svg" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_jx3bdjdo0 PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0idXRmLTgiPz4KPCEtLSBHZW5lcmF0b3I6IEFk b2JlIElsbHVzdHJhdG9yIDIzLjAuNCwgU1ZHIEV4cG9ydCBQbHVnLUluIC4gU1ZHIFZlcnNpb246 IDYuMDAgQnVpbGQgMCkgIC0tPgo8c3ZnIHZlcnNpb249IjEuMSIgaWQ9IkxheWVyXzEiIHhtbG5z PSJodHRwOi8vd3d3LnczLm9yZy8yMDAwL3N2ZyIgeG1sbnM6eGxpbms9Imh0dHA6Ly93d3cudzMu b3JnLzE5OTkveGxpbmsiIHg9IjBweCIgeT0iMHB4IgoJIHZpZXdCb3g9IjAgMCAxNzkyIDE3OTIi IHN0eWxlPSJlbmFibGUtYmFja2dyb3VuZDpuZXcgMCAwIDE3OTIgMTc5MjsiIHhtbDpzcGFjZT0i cHJlc2VydmUiPgo8c3R5bGUgdHlwZT0idGV4dC9jc3MiPgoJLnN0MHtmaWxsOiNGRkZGRkY7fQo8 L3N0eWxlPgo8dGl0bGU+c2F2ZV9kYXRhX2NoYW5nZXM8L3RpdGxlPgo8cGF0aCBkPSJNNTc2LDE0 NDB2LTE5MmMwLTkuMy0zLTE3LTktMjNzLTEzLjctOS0yMy05SDIyNGMtOS4zLDAtMTcsMy0yMyw5 cy05LDEzLjctOSwyM3YxOTJjMCw5LjMsMywxNyw5LDIzczEzLjcsOSwyMyw5aDMyMAoJYzkuMyww LDE3LTMsMjMtOVM1NzYsMTQ0OS4zLDU3NiwxNDQweiBNNTc2LDEwNTZWODY0YzAtOS4zLTMtMTct OS0yM3MtMTMuNy05LTIzLTlIMjI0Yy05LjMsMC0xNywzLTIzLDlzLTksMTMuNy05LDIzdjE5MgoJ YzAsOS4zLDMsMTcsOSwyM3MxMy43LDksMjMsOWgzMjBjOS4zLDAsMTctMywyMy05UzU3NiwxMDY1 LjMsNTc2LDEwNTZ6IE0xMDg4LDE0NDB2LTE5MmMwLTkuMy0zLTE3LTktMjNzLTEzLjctOS0yMy05 SDczNgoJYy05LjMsMC0xNywzLTIzLDlzLTksMTMuNy05LDIzdjE5MmMwLDkuMywzLDE3LDksMjNz MTMuNyw5LDIzLDloMzIwYzkuMywwLDE3LTMsMjMtOVMxMDg4LDE0NDkuMywxMDg4LDE0NDB6IE01 NzYsNjcyVjQ4MAoJYzAtOS4zLTMtMTctOS0yM3MtMTMuNy05LTIzLTlIMjI0Yy05LjMsMC0xNywz LTIzLDlzLTksMTMuNy05LDIzdjE5MmMwLDkuMywzLDE3LDksMjNzMTMuNyw5LDIzLDloMzIwYzku MywwLDE3LTMsMjMtOQoJUzU3Niw2ODEuMyw1NzYsNjcyeiBNMTA4OCwxMDU2Vjg2NGMwLTkuMy0z LTE3LTktMjNzLTEzLjctOS0yMy05SDczNmMtOS4zLDAtMTcsMy0yMyw5cy05LDEzLjctOSwyM3Yx OTJjMCw5LjMsMywxNyw5LDIzCglzMTMuNyw5LDIzLDloMzIwYzkuMywwLDE3LTMsMjMtOVMxMDg4 LDEwNjUuMywxMDg4LDEwNTZ6IE0xNjAwLDE0NDB2LTE5MmMwLTkuMy0zLTE3LTktMjNzLTEzLjct OS0yMy05aC0zMjBjLTkuMywwLTE3LDMtMjMsOQoJcy05LDEzLjctOSwyM3YxOTJjMCw5LjMsMywx Nyw5LDIzczEzLjcsOSwyMyw5aDMyMGM5LjMsMCwxNy0zLDIzLTlTMTYwMCwxNDQ5LjMsMTYwMCwx NDQweiBNMTA4OCw2NzJWNDgwYzAtOS4zLTMtMTctOS0yMwoJcy0xMy43LTktMjMtOUg3MzZjLTku MywwLTE3LDMtMjMsOXMtOSwxMy43LTksMjN2MTkyYzAsOS4zLDMsMTcsOSwyM3MxMy43LDksMjMs OWgzMjBjOS4zLDAsMTctMywyMy05UzEwODgsNjgxLjMsMTA4OCw2NzJ6CgkgTTE2MDAsMTA1NlY4 NjRjMC05LjMtMy0xNy05LTIzcy0xMy43LTktMjMtOWgtMzIwYy05LjMsMC0xNywzLTIzLDlzLTks MTMuNy05LDIzdjE5MmMwLDkuMywzLDE3LDksMjNzMTMuNyw5LDIzLDloMzIwCgljOS4zLDAsMTct MywyMy05UzE2MDAsMTA2NS4zLDE2MDAsMTA1NnogTTE2MDAsNjcyVjQ4MGMwLTkuMy0zLTE3LTkt MjNzLTEzLjctOS0yMy05aC0zMjBjLTkuMywwLTE3LDMtMjMsOXMtOSwxMy43LTksMjN2MTkyCglj MCw5LjMsMywxNyw5LDIzczEzLjcsOSwyMyw5aDMyMGM5LjMsMCwxNy0zLDIzLTlTMTYwMCw2ODEu MywxNjAwLDY3MnogTTE3MjgsMzUydjEwODhjMCw0NC0xNS43LDgxLjctNDcsMTEzcy02OSw0Ny0x MTMsNDdIMjI0CgljLTQ0LDAtODEuNy0xNS43LTExMy00N3MtNDctNjktNDctMTEzVjM1MmMwLTQ0 LDE1LjctODEuNyw0Ny0xMTNzNjktNDcsMTEzLTQ3aDEzNDRjNDQsMCw4MS43LDE1LjcsMTEzLDQ3 UzE3MjgsMzA4LDE3MjgsMzUyeiIvPgo8Zz4KCTxwYXRoIGQ9Ik04OTYsMTM5Ni44Yy0yNS41LDAt NDguNC05LjQtNjYuMi0yNy4zbC0zMjUuMi0zMjUuN2MtMTguNC0xNy41LTI4LjEtNDAuNS0yOC4x LTY2LjVjMC0yNS44LDkuMy00OC4yLDI3LjctNjYuNmwzNi45LTM3LjQKCQljMC4yLTAuMiwwLjUt MC41LDAuNy0wLjdjMTguNS0xNy41LDQxLjMtMjYuNyw2Ni4xLTI2LjdjMjUuNSwwLDQ4LjQsOS40 LDY2LjIsMjcuM2w5NS44LDk1LjhWNjg5LjJjMC0yNS4xLDkuNi00OCwyNy44LTY2LjIKCQljMTgu Mi0xOC4yLDQxLjEtMjcuOCw2Ni4yLTI3LjhoNjRjMjUuMSwwLDQ4LDkuNiw2Ni4yLDI3LjhjMTgu MiwxOC4yLDI3LjgsNDEuMSwyNy44LDY2LjJ2Mjc5LjZsOTUuOC05NS44CgkJYzE3LjktMTcuOSw0 MC43LTI3LjMsNjYuMi0yNy4zYzI0LjgsMCw0Ny43LDkuMiw2Ni4xLDI2LjdjMC4yLDAuMiwwLjQs MC40LDAuNiwwLjZsMzcuNSwzNy41YzAuMiwwLjIsMC40LDAuNCwwLjYsMC42CgkJYzE3LjUsMTgu NSwyNi43LDQxLjMsMjYuNyw2Ni4xYzAsMjUuNS05LjQsNDguNC0yNy4zLDY2LjJsLTMyNS41LDMy NmMtMC4yLDAuMi0wLjQsMC40LTAuNiwwLjYKCQlDOTQzLjcsMTM4Ny41LDkyMC44LDEzOTYuOCw4 OTYsMTM5Ni44eiIvPgoJPHBhdGggY2xhc3M9InN0MCIgZD0iTTkyOCw2MjUuMmMxNy4zLDAsMzIu Myw2LjMsNDUsMTlzMTksMjcuNywxOSw0NXYzNTJsMTQ3LTE0N2MxMi4zLTEyLjMsMjcuMy0xOC41 LDQ1LTE4LjUKCQljMTcuMywwLDMyLjUsNi4yLDQ1LjUsMTguNWwzNy41LDM3LjVjMTIuMywxMywx OC41LDI4LjIsMTguNSw0NS41YzAsMTcuNy02LjIsMzIuNy0xOC41LDQ1bC0zMjUuNSwzMjYKCQlj LTEzLDEyLjMtMjguMiwxOC41LTQ1LjUsMTguNWMtMTcuNywwLTMyLjctNi4yLTQ1LTE4LjVsLTMy NS41LTMyNmMtMTIuNy0xMi0xOS0yNy0xOS00NWMwLTE3LjcsNi4zLTMyLjgsMTktNDUuNWwzNy0z Ny41CgkJYzEzLTEyLjMsMjguMi0xOC41LDQ1LjUtMTguNWMxNy43LDAsMzIuNyw2LjIsNDUsMTgu NWwxNDcsMTQ3di0zNTJjMC0xNy4zLDYuMy0zMi4zLDE5LTQ1czI3LjctMTksNDUtMTlIOTI4IE05 MjgsNTY1LjJoLTY0CgkJYy0zMy4zLDAtNjMuNSwxMi42LTg3LjQsMzYuNkM3NTIuNiw2MjUuOCw3 NDAsNjU2LDc0MCw2ODkuMnYyMDcuMWwtNDQuNi00NC42Yy0yMy42LTIzLjYtNTMuOC0zNi4xLTg3 LjQtMzYuMQoJCWMtMzIuNiwwLTYyLjYsMTIuMS04Ni43LDM0LjljLTAuNSwwLjUtMSwxLTEuNSwx LjRsLTM2LjksMzcuNGMtMjMuOCwyMy45LTM2LjQsNTQuMi0zNi40LDg3LjhjMCwzNC4zLDEyLjgs NjQuNiwzNy4xLDg3LjkKCQlsMzI1LDMyNS41YzIzLjYsMjMuNiw1My45LDM2LjEsODcuNSwzNi4x YzMyLjYsMCw2Mi42LTEyLjEsODYuNy0zNC45YzAuNC0wLjQsMC44LTAuOCwxLjItMS4ybDMyNS41 LTMyNgoJCWMyMy42LTIzLjYsMzYtNTMuOCwzNi04Ny40YzAtMzIuNi0xMi4xLTYyLjYtMzQuOS04 Ni43Yy0wLjQtMC40LTAuOC0wLjgtMS4yLTEuMmwtMzcuNS0zNy41Yy0wLjQtMC40LTAuOC0wLjgt MS4yLTEuMgoJCWMtMjQuMS0yMi44LTU0LjEtMzQuOS04Ni43LTM0LjljLTMzLjYsMC02My44LDEy LjUtODcuNCwzNi4xbC00NC42LDQ0LjZWNjg5LjJjMC0zMy4zLTEyLjYtNjMuNS0zNi42LTg3LjQK CQlDOTkxLjUsNTc3LjksOTYxLjMsNTY1LjIsOTI4LDU2NS4yTDkyOCw1NjUuMnoiLz4KPC9nPgo8 L3N2Zz4K --000000000000c459e3058badcc5a--