I was researching about how to catch errors in javascript. I faced a
problem. due to the way javascript works for a try block to catch an
error it has to be within the context of execution which means in the
following code:
try {
function f(){
throw new Error()
}
} catch (e) {}
calling f(); the error will not be caught in the try block.
essentially what this means is that if we need to catch the errors
using try and catch blocks we need to wrap the inside of every
function with a try block. I am not sure how feasible is this idea but
it I am sure it would reduce code readability.
The other option is using window.onerror which allows you to hook a
function that gets executed whenever an uncaught exception occurs.
This is obviously much simpler and less invasive and has an upside
that errors in any context anywhere will still be reported to the
hooked function. But there is a catch. which is that window.onerror
does not provide a stacktrace because it is executed in a different
context from the error itself. what it has access to is the line
number, file name and exception message.
so my question is which method should I use, the surrounding all
functions by try blocks or using the window.onerror callback method?
how important is the stacktrace?
Hi,
I'm seeing some oddities in the demo server when using the Drizzle
backend. I'm not sure if these are problems with phpMyAdmin,
shortcomings of Drizzle itself, or inconsistencies due to user error
(though I think I've waited long enough for the server to reset). So I
wanted to get a second opinion before opening tickets.
1) There is no Users tab displayed on the main page
2) Clicking the + button to expand the navigation tree has no effect
On Mon, Jun 24, 2013 at 11:41 AM, Ayush Chaudhary <ayushchd(a)gmail.com>wrote:
> Hi,
>
> I was testing Tracker.class.php. There are a quite a few
> assertions related to database queries I might need to implement. I wanted
> to know what would be the best approach between using dummy queries and
> mocking the database interface class.
>
> What I thought was to use dummy queries when the SQL query is a SELECT
> statement and the result of the query is being further used.
>
> Please advice.
>
> Thanks!
> --
> Ayush Chaudhary
>
>
Hi Ayush,
Dummy DBI and mocking has it's own advantages and choosing between them
should be based on the case at hand. Dummy DBI would make it easy to add a
common behavior for a query that is used in more than one test case where
the expected output of all the tests are the same. On the other hand
mocking would give you more control over the behavior. If different tests
need to see the database interface return different results for the same
query, you have no choice other than mocking.
Another situation where you cannot use dummy DBI is ascertaining the
correctness of the queries generated. For example, in Node::getData() to
test the correctness of the generated query you need to use mocking. In
this case the solution would be to create a mock database interface which
expected the correct query just once.
--
Thanks and Regards,
Madhura Jayaratne
Hi Supun,
If you are looking for further ideas about refactoring, I have suggestions.
First, have a look at tbl_select.php, both in the QA_3_5 and the QA_4_0
branches, and see what kind of high-level calls have been left in this
refactored script. Everything else went to functions. In this case, Atul
also OOPed the code, which is only expected from you if you have time,
as it's not part of your proposal.
All chunks of code having a common goal (see for example the "Bookmark
add" section) should be extracted to sql.lib.php.
I was pretty sure you were aware of this, as your proposal plans to
spend 6 weeks x 40 hours on refactoring sql.php.
Second, as discussed previously, your proposal says "The sql.php is a
very large script and is also one of the central components in
phpMyAdmin. As it is large it is hard to read and maintain. It needs
refactoring and better integration with other scripts calling it."
So, all scripts that are including sql.php (for example db_qbe.php)
should probably be including a library file then call a high-level
function. Hint: sql.php's main job is to deal with $sql_query.
--
Marc Delisle
http://infomarc.info
Uglifying js code would prevent any meaningful reports from reaching
us in the error reporting system since all function and variable names
are useless and all the scripts are inlined. I am suggesting that we
refrain from uglifing js code in production. Since bandwidth is now
sufficiently large to handle pretty js code in production. It would
give us access to a wealth of info to help us diagnose and reproduce
error reports that may not be feasible with ugly js scripts.
what do you think?
See <http://ci.phpmyadmin.net/job/phpMyAdmin-continuous/3678/changes>
Changes:
[weblate] Translated using Weblate (Hindi)
[weblate] Translated using Weblate (Traditional Chinese)
------------------------------------------
Started by GitHub push by weblate
Building in workspace <http://ci.phpmyadmin.net/job/phpMyAdmin-continuous/ws/>
Checkout:workspace / <http://ci.phpmyadmin.net/job/phpMyAdmin-continuous/ws/> - hudson.remoting.LocalChannel@dbf2988
Using strategy: Default
Last Built Revision: Revision 7eb560877d23b52a248feed9c030a01c3271cee6 (origin/master)
Fetching changes from 1 remote Git repository
Fetching upstream changes from origin
Commencing build of Revision 592b86156c760a9dd70afb5d8e8041ec90351bf6 (origin/master)
Checking out Revision 592b86156c760a9dd70afb5d8e8041ec90351bf6 (origin/master)
[workspace] $ /bin/sh -xe /tmp/hudson2107526584297685716.sh
+ ./scripts/generate-mo --quiet
po/zh_TW.po:12249: 'msgstr' is not a valid PHP format string, unlike 'msgid'. Reason: The character that terminates the directive number 1 is not a valid conversion specifier.
msgfmt: found 1 fatal error
Build step 'Execute shell' marked build as failure
[CHECKSTYLE] Skipping publisher since build result is FAILURE
[DRY] Collecting duplicate code analysis files...
[DRY] Finding all files that match the pattern build/logs/pmd-cpd.xml
[DRY] Parsing 1 files in <http://ci.phpmyadmin.net/job/phpMyAdmin-continuous/ws/>
[DRY] Successfully parsed file <http://ci.phpmyadmin.net/job/phpMyAdmin-continuous/ws/build/logs/pmd-cpd.xml> of module with 38 warnings.
[DRY] Computing warning deltas based on reference build #3677
[TASKS] Skipping publisher since build result is FAILURE
[ANALYSIS-COLLECTOR] Computing warning deltas based on reference build #3677
Recording plot data
[xUnit] [INFO] - Starting to record.
[xUnit] [INFO] - Processing PHPUnit-3.x (default)
[xUnit] [INFO] - [PHPUnit-3.x (default)] - 1 test report file(s) were found with the pattern 'build/logs/junit.xml' relative to '<http://ci.phpmyadmin.net/job/phpMyAdmin-continuous/ws/'> for the testing framework 'PHPUnit-3.x (default)'.
[xUnit] [ERROR] - Test reports were found but not all of them are new. Did all the tests run?
* <http://ci.phpmyadmin.net/job/phpMyAdmin-continuous/ws/build/logs/junit.xml> is 3 min 0 sec old
[xUnit] [INFO] - Fail BUILD because 'set build failed if errors' option is activated.
[xUnit] [INFO] - There are errors when processing test results.
[xUnit] [INFO] - Skipping tests recording.
[xUnit] [INFO] - Stop build.
Should I allow the user to submit error reports automatically without
looking or adding his description to the events that lead to the error
page. Currently I have two options for sending error reports. one is
never send error report and the second is always ask to send. in the
project description you wanted a third option to automatically send an
error report. should I allow this option given that the user will not
have the ability to add steps to reproduce the error to the report?
Hi all,
I have been working on this feature during the last couple of days and I've
sent a pull request [1] containing what I've done.
With the changes the long dropdown to select foreign column has been split
to two dropdowns, one to select the foreign table and the other to select
the foreign column. I have also extended this to support cross database
relations with an additional dropdown to select the foreign database.
So when the user selects the database, the entries in the table dropdown
are filtered only to show tables in that database and column dropdown is
filtered in a similar manner when a table is selected. Own database is
selected by default as it's more common to setup relations inside the same
database.
Checking relational integrity feature was already supporting cross database
relations. I've added table name to the displayed text to make it clearer.
I have also updated a couple of FAQs in the documentation related to these
features.
I would be grateful if you could check out this feature and suggest any
improvements.
[1] https://github.com/phpmyadmin/phpmyadmin/pull/438
--
Regards
Kasun Chathuranga