phpMyAdmin

Le 2012-10-28 02:21, Chanaka Dharmarathna a écrit :
> Hi,
> 
> I'm working on bug [0].
> Relevant modifications to the sql query is done inside tbl_export.php,
> according to the selected results from the table browse window which is
> going to export. When modifying the query, it actually rebuild from the
> scratch.
> 
> As I understand there are 2 requirements for modify the query.
> 1. Remove the LIMIT clause (for append any where clause)
> 2. Add needed filtering clause (additional where clause)
> 
> To do the above things is it really need to rebuild the query from the
> scratch ?
> I don't think that there are scenarios which need to modify the beginning
> part of he query (before where clause). So is it okay to modify the query
> only from the where clause. Though the current analyzer doesn't support for
> the multiple select statements, hopefully this will fix the bug I mentioned.
> Any thoughts on this ?

Chanaka,
I believe this is going to be tricky to solve, because there could be
many WHERE clauses (in the main SELECT and in the subselect).

By the way, the original code was [1].

[1] https://github.com/phpmyadmin/phpmyadmin/commit/3a558d15

> 
> [0] :
> http://sourceforge.net/tracker/?func=detail&aid=3034670&group_id=23067&atid=377408
> 
> Regards !



-- 
Marc Delisle
http://infomarc.info

> > I'm working on bug [0].
> > Relevant modifications to the sql query is done inside tbl_export.php,
> > according to the selected results from the table browse window which is
> > going to export. When modifying the query, it actually rebuild from the
> > scratch.
> >
> > As I understand there are 2 requirements for modify the query.
> > 1. Remove the LIMIT clause (for append any where clause)
> > 2. Add needed filtering clause (additional where clause)
> >
> > To do the above things is it really need to rebuild the query from the
> > scratch ?
> > I don't think that there are scenarios which need to modify the beginning
> > part of he query (before where clause). So is it okay to modify the query
> > only from the where clause. Though the current analyzer doesn't support
> for
> > the multiple select statements, hopefully this will fix the bug I
> mentioned.
> > Any thoughts on this ?
>
> Chanaka,
> I believe this is going to be tricky to solve, because there could be
> many WHERE clauses (in the main SELECT and in the subselect).
>

Hi Marc,

I mean for any case even it has multiple where clauses, the select part
will not be changed. Rebuilding this first part messing up the query if
there are sub queries. In following query unchanged first part is in bold.
*SELECT `id`, `name` FROM `customers`* WHERE id NOT IN ( SELECT id FROM
companies WHERE name LIKE '%u%')

Apart from that, SQL with several where clauses, can be represented as a
one SQL query (without any sub queries and with only one where clause).
Currently that's reached by using the primary key values of the resulted
table rows which are going to export.

But when building new where clause, other than only combining those primary
key values with 'OR' clause, at the end another clause is appended which is
from analyzed sql [0]. That where clause is the last where clause of the
original SQL query. I don't see any use of this since we already can
identify the rows by primary key.

Your thoughts on this will be very helpful to go forward correctly.

[0] :
https://github.com/phpmyadmin/phpmyadmin/blob/master/tbl_export.php#L61

Regards !
-- 
Chanaka Dharmarathna
*Virtusa (Pvt) Ltd. | **Sri Lanka*

Marc Delisle a écrit :
> Hi,
> It would be annoying to display a hint on mouseover for all 
> grid-editable cells.
> 
> To help 3.5.x users learn about the double-click (which is now the 
> default action for grid editing in 4.0), we could display a hint when 
> the user clicks on the data row (which has the effect of selecting the 
> row, like the checkbox). However we must take care of displaying this 
> hint just once (per session?).
> 
> Also, what about removing the "select row on click" feature? Is this 
> intuitive?
> 
> Comments?
> 

Anyone?

-- 
Marc Delisle
http://infomarc.info

Hi

Dne Sat, 20 Oct 2012 08:13:27 -0700
Marc Delisle <marc@...> napsal(a):

> It would be annoying to display a hint on mouseover for all 
> grid-editable cells.
> 
> To help 3.5.x users learn about the double-click (which is now the 
> default action for grid editing in 4.0), we could display a hint when 
> the user clicks on the data row (which has the effect of selecting the 
> row, like the checkbox). However we must take care of displaying this 
> hint just once (per session?).

I'd rather make some one help dialog, which will show help for all
manipulations with browse view (sorting, choosing columns, moving
columns, grid editing).

Then we could show it in similar way github is offering Keyboard
shortcuts:

https://github.com/nijel/weblate/commits/master

> Also, what about removing the "select row on click" feature? Is this 
> intuitive?

I think it pretty much collides with grid editing, so I'd be for
removing it.

-- 
	Michal Čihař | http://cihar.com | http://phpmyadmin.net

Le 2012-10-24 08:09, Michal Čihař a écrit :
> Hi
> 
> Dne Sat, 20 Oct 2012 08:13:27 -0700
> Marc Delisle <marc@...> napsal(a):
> 
>> It would be annoying to display a hint on mouseover for all 
>> grid-editable cells.
>>
>> To help 3.5.x users learn about the double-click (which is now the 
>> default action for grid editing in 4.0), we could display a hint when 
>> the user clicks on the data row (which has the effect of selecting the 
>> row, like the checkbox). However we must take care of displaying this 
>> hint just once (per session?).
> 
> I'd rather make some one help dialog, which will show help for all
> manipulations with browse view (sorting, choosing columns, moving
> columns, grid editing).
> 
> Then we could show it in similar way github is offering Keyboard
> shortcuts:
> 
> https://github.com/nijel/weblate/commits/master

This is an interesting idea, but I also like the current way that help
is given (in context with the pointer).
> 
>> Also, what about removing the "select row on click" feature? Is this 
>> intuitive?
> 
> I think it pretty much collides with grid editing, so I'd be for
> removing it.



-- 
Marc Delisle
http://infomarc.info

Hi

Dne Wed, 24 Oct 2012 09:14:46 -0400
Marc Delisle <marc@...> napsal(a):

> This is an interesting idea, but I also like the current way that help
> is given (in context with the pointer).

The problem I see with this is that there is too many context help
already - you can basically hover about any part of table title to get
some help on it.

-- 
	Michal Čihař | http://cihar.com | http://blog.cihar.com

Michal Čihař a écrit :
> Hi
> 
> Dne Wed, 24 Oct 2012 09:14:46 -0400
> Marc Delisle <marc@...> napsal(a):
> 
>> This is an interesting idea, but I also like the current way that help
>> is given (in context with the pointer).
> 
> The problem I see with this is that there is too many context help
> already - you can basically hover about any part of table title to get
> some help on it.

It's the first time I see a complaint about this context help.

-- 
Marc Delisle
http://infomarc.info

2012/10/18 Michal Čihař <michal@...>:
> Hi all
>
> I've just enabled Travis CI on Github. In basic, it runs our testsuite
> on every commit, but supports using more PHP versions compared to
> Jenkins. You can see results here:
>
> https://travis-ci.org/#!/phpmyadmin/phpmyadmin
>
> But it also provides support for testing pull requests and displaying
> it's status just at the pull request. This will allow you to directly
> see if pull request would break anything or not. You can see examples
> on Github and Travis blogs:
>
> https://github.com/blog/1227-commit-status-api
>
> http://about.travis-ci.org/blog/2012-09-04-pull-requests-just-got-even-more-awesome/
>
> Please note that this won't replace Jenkins, it's just an additional
> source, mostly to help with the pull requests.
>

Nice! Especially the pull-request support is very useful!

-- 
Kind regards,

Dieter Adriaenssens

Michal Čihař a écrit :
> Hi all
> 
> I've just enabled Travis CI on Github. In basic, it runs our testsuite
> on every commit, but supports using more PHP versions compared to
> Jenkins. You can see results here:
> 
> https://travis-ci.org/#!/phpmyadmin/phpmyadmin
> 
> But it also provides support for testing pull requests and displaying
> it's status just at the pull request. This will allow you to directly
> see if pull request would break anything or not. You can see examples
> on Github and Travis blogs:

Thanks Michal; another initiative that reminds us that our code coverage 
is only at the 50% level.

-- 
Marc Delisle
http://infomarc.info

Le 2012-10-14 10:04, Dieter Adriaenssens a écrit :
> Hi,
> 
> I don't find any clear rules on when to add/update translatable
> strings (from the developer point of view). I have a suggestions :
> 
> master (dev) :
> - freely add and change translatable strings
> 
> when preparing a future stable (4.0-alpha/rc)
> - no new translatable strings
> - no updates that changes the content/meaning of a translatable string
> (but exceptions allowed after discussion on mailing list)
> - updates fixing typos and grammar are allowed
> 
> current stable (QA_3_5)
> - no new translatable strings
> - no updates that changes the content/meaning of a translatable string
> - updates fixing typos and grammar are allowed
> 
> old releases
> - no maintance on translatable strings (no new strings, no fixes on
> existing strings)
> 
> 
> What do you think?
> BTW : the reason I mentioned allowing grammar/typo fixes in current
> stable, is because it has almost no influence on the translating
> process. A string with an fixed typo does not have to be retranslated.
> 

Fine by me.

-- 
Marc Delisle
http://infomarc.info

Hi

Dne Sun, 14 Oct 2012 16:04:45 +0200
Dieter Adriaenssens <dieter.adriaenssens@...> napsal(a):

> I don't find any clear rules on when to add/update translatable
> strings (from the developer point of view). I have a suggestions :

These are basically okay, maybe this should be put into wiki?

> master (dev) :
> - freely add and change translatable strings
> 
> when preparing a future stable (4.0-alpha/rc)
> - no new translatable strings
> - no updates that changes the content/meaning of a translatable string
> (but exceptions allowed after discussion on mailing list)
> - updates fixing typos and grammar are allowed
> 
> current stable (QA_3_5)
> - no new translatable strings
> - no updates that changes the content/meaning of a translatable string
> - updates fixing typos and grammar are allowed
> 
> old releases
> - no maintance on translatable strings (no new strings, no fixes on
> existing strings)
> 
> 
> What do you think?
> BTW : the reason I mentioned allowing grammar/typo fixes in current
> stable, is because it has almost no influence on the translating
> process. A string with an fixed typo does not have to be retranslated.

These are okay as long as you change source string in all po files,
otherwise the strings will appear as fuzzy and will require attention
from translators.

-- 
	Michal Čihař | http://cihar.com | http://blog.cihar.com

2012/10/16 Michal Čihař <michal@...>:
> Hi
>
> Dne Sun, 14 Oct 2012 16:04:45 +0200
> Dieter Adriaenssens <dieter.adriaenssens@...> napsal(a):
>
>> I don't find any clear rules on when to add/update translatable
>> strings (from the developer point of view). I have a suggestions :
>
> These are basically okay, maybe this should be put into wiki?

That's the idea, but I wanted to check with the other developers first.
I'll put it on later today.

>> master (dev) :
>> - freely add and change translatable strings
>>
>> when preparing a future stable (4.0-alpha/rc)
>> - no new translatable strings
>> - no updates that changes the content/meaning of a translatable string
>> (but exceptions allowed after discussion on mailing list)
>> - updates fixing typos and grammar are allowed
>>
>> current stable (QA_3_5)
>> - no new translatable strings
>> - no updates that changes the content/meaning of a translatable string
>> - updates fixing typos and grammar are allowed
>>
>> old releases
>> - no maintance on translatable strings (no new strings, no fixes on
>> existing strings)
>>
>>
>> What do you think?
>> BTW : the reason I mentioned allowing grammar/typo fixes in current
>> stable, is because it has almost no influence on the translating
>> process. A string with an fixed typo does not have to be retranslated.
>
> These are okay as long as you change source string in all po files,
> otherwise the strings will appear as fuzzy and will require attention
> from translators.

What do you mean by 'all po files'? Is running po-update sufficient?
Or do you mean it has to be changed in every branch were the string
exists?

-- 
Kind regards,

Dieter Adriaenssens

Hi

Dne Tue, 16 Oct 2012 13:18:21 +0200
Dieter Adriaenssens <dieter.adriaenssens@...> napsal(a):

> 2012/10/16 Michal Čihař <michal@...>:
> > These are okay as long as you change source string in all po files,
> > otherwise the strings will appear as fuzzy and will require attention
> > from translators.
> 
> What do you mean by 'all po files'? Is running po-update sufficient?
> Or do you mean it has to be changed in every branch were the string
> exists?

The update-po script just takes strings and updates po file to match
them. In case some source string has been changed, translation will be
marked as fuzzy. It simply can not detect whether change is important
for translation or not.

In case you're sure this is just a typo, that is not affecting
translations, you should change the source string manually [*] in po
files prior to running update-po.

[*]: Or rather by some something like:

sed -i 's/this is typo/this is a typo/' po/*.po

-- 
	Michal Čihař | http://cihar.com | http://blog.cihar.com

2012/10/16 Michal Čihař <michal@...>:
> Hi
>
> Dne Tue, 16 Oct 2012 13:18:21 +0200
> Dieter Adriaenssens <dieter.adriaenssens@...> napsal(a):
>
>> 2012/10/16 Michal Čihař <michal@...>:
>> > These are okay as long as you change source string in all po files,
>> > otherwise the strings will appear as fuzzy and will require attention
>> > from translators.
>>
>> What do you mean by 'all po files'? Is running po-update sufficient?
>> Or do you mean it has to be changed in every branch were the string
>> exists?
>
> The update-po script just takes strings and updates po file to match
> them. In case some source string has been changed, translation will be
> marked as fuzzy. It simply can not detect whether change is important
> for translation or not.
>
> In case you're sure this is just a typo, that is not affecting
> translations, you should change the source string manually [*] in po
> files prior to running update-po.
>
> [*]: Or rather by some something like:
>
> sed -i 's/this is typo/this is a typo/' po/*.po

Added it to the wiki [0], along with the guidelines on when to
add/update messages.

[0] http://wiki.phpmyadmin.net/pma/Gettext_for_developers

Kind regards,

Dieter

> --
>         Michal Čihař | http://cihar.com | http://blog.cihar.com
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Phpmyadmin-devel mailing list
> Phpmyadmin-devel@...
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel



-- 
Kind regards,

Dieter Adriaenssens

Hi

Dne Tue, 16 Oct 2012 14:17:28 +0200
Dieter Adriaenssens <dieter.adriaenssens@...> napsal(a):

> Added it to the wiki [0], along with the guidelines on when to
> add/update messages.
> 
> [0] http://wiki.phpmyadmin.net/pma/Gettext_for_developers

Thanks, I've also added explicit section about fixing typos.

-- 
	Michal Čihař | http://cihar.com | http://blog.cihar.com

On Oct 13, 2012, at 9:13 AM, Marc Delisle <marc@...> wrote:

> Hi,
> 
> In current master, when the UploadDir feature is activated and a
> database is empty, clicking on Import produces:
> 
> Fatal error: Call to a member function getExtension() on a non-object in
> libraries/Util.class.php on line 3465
> 
> Even if this could be debugged, I would like to just remove support for
> the docSQL import format. The docSQL project has had no activity in the
> last ten years.
> 

Dropping it is fine by me. I don't recall anyone in the IRC channel mentioning that format in some time. 

> -- 
> Marc Delisle
> http://infomarc.info
> 
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> Phpmyadmin-devel mailing list
> Phpmyadmin-devel@...
> https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel

Le 2012-10-08 14:24, Chanaka Dharmarathna a écrit :
> Hi,
> 
> Currently there is no 'LIKE %...%' operator for the numeric fields in table
> search screen. But there are some scenarios we need to search the numeric
> fields (int, date etc) with 'LIKE' operator + wildcard characters (LIKE
> %2012%). So, was there any reason for not using that previously ?
> If we can give the support for this, it hopefully provide a different way
> to bypass the problem in bug [0]. Any thoughts on this ?
> 
> [0] :
> https://sourceforge.net/tracker/index.php?func=detail&aid=3573456&group_id=23067&atid=377408
> 
> Regards !

Hi Chanaka,
I don't see a reason for not offering this (but take care of not showing
this option by default, as the leading % wildcard bypasses any index.

-- 
Marc Delisle
http://infomarc.info

> > Currently there is no 'LIKE %...%' operator for the numeric fields in
> table
> > search screen. But there are some scenarios we need to search the numeric
> > fields (int, date etc) with 'LIKE' operator + wildcard characters (LIKE
> > %2012%). So, was there any reason for not using that previously ?
> > If we can give the support for this, it hopefully provide a different way
> > to bypass the problem in bug [0]. Any thoughts on this ?
> >
> > [0] :
> >
> https://sourceforge.net/tracker/index.php?func=detail&aid=3573456&group_id=23067&atid=377408
> >
> > Regards !
>
> Hi Chanaka,
> I don't see a reason for not offering this (but take care of not showing
> this option by default, as the leading % wildcard bypasses any index.
>

Hi Marc,

You mean in any case ? No, currently it only included to text operators.
I'll add this operator to numeric fiels.

Regards !
-- 
Chanaka Dharmarathna
*Virtusa (Pvt) Ltd. | **Sri Lanka*