Stored Procedures in MySQL

Working with Stored Procedures in MySQL

Writing the first stored procedure

The first stored procedure is very simple. It retrieves all products from products table. First let’s take a look at the stored procedure source code below:

1	DELIMITER //
2	CREATE PROCEDURE GetAllProducts()

3	BEGIN
4	SELECT *  FROM products;

5	END //
6	DELIMITER ;

The first command you see is DELIMITER //. This command is not related to the stored procedure. DELIMITER statement in MySQL is used to change the standard delimiter (semicolon) to another. In this case, the delimiter is changed from semicolon(;) to //, so you can have multiple SQL statements inside stored procedure which can be separated by the semicolon. After the END keyword we use delimiter // to show the end of the stored procedure. The last command changes the delimiter back to the standard one (semicolon).
more

Stored Procedures in Oracle

Working with Stored Procedures in Oracle

Procedures are written in Oracle's PL/SQL programming language.
Sample Procedure
In Notepad, type:
CREATE OR REPLACE PROCEDURE sample
IS
BEGIN
  NULL;
END;
Save your file as sample.sql.
Let’s go through the procedure line by line. The lines are numbered for your convenience:
1 CREATE OR REPLACE PROCEDURE sample
2 IS
3 BEGIN
4   NULL;
5 END;
Line 1:
CREATE OR REPLACE PROCEDURE is an SQL statement that instructs Oracle to create a procedure called sample, and to overwrite it if it exists.
Line 2:
The IS keyword signals that a PL/SQL body will follow.
Line 3:
The BEGIN keyword signals the start of a PL/SQL body.
Line 4:
The NULL PL/SQL statement indicates that no action should be performed. We cannot just leave it out, because at least one statement is required in a PL/SQL body.
Line 5:
The END keyword signals the end of the PL/SQL block.
Now let's move on to creating a procedure.


Read more

JavaScript : Comaprison of Objects

JavaScript has two different ways of comparing the values of objects for equality.
The equals operator
The equals operator consists of two equal signs: ==
JavaScript features weak typing, that means, that the equals operator coerces types in order to compare them.

""           ==   "0"           // false
0            ==   ""            // true
0            ==   "0"           // true
false        ==   "false"       // false
false        ==   "0"           // true
false        ==   undefined     // false
false        ==   null          // false
null         ==   undefined     // true
" \t\r\n"    ==   0             // true
The above table shows the results of the type coercion and it is the main reason why the use of == is widely regarded as bad practice,
it introduces hard to track down bugs due to its complicated conversion rules.
Additionally there is also a performance impact when type coercion is in play;
for example, a string has to be converted to a number before it can be compared to another number.

The strict equals operator
The strict equals operator consists of three equal signs: ===
Other than the normal equals operator, the strict equals operator does not perform type coercion between its operands.


""           ===   "0"           // false
0            ===   ""            // false
0            ===   "0"           // false
false        ===   "false"       // false
false        ===   "0"           // false
false        ===   undefined     // false
false        ===   null          // false
null         ===   undefined     // false
" \t\r\n"    ===   0             // false
The above results are a lot clearer and allow for early breakage of code.
This hardens code to a certain degree and also gives performance improvements in case the operands are of different types.
Comparing objects
While both == and === are stated as equality operators, they behave different when at least one of their operands happens to be an Object.

{} === {};                            // false
new String('foo') === 'foo';  // false
new Number(10) === 10;   // false
var foo = {};foo === foo;    // true
Here both operators compare for identity and not equality; that is, they will compare for the same instance of the object, much like is in Python and a pointer comparison in C do.
Conclusion
It is highly recommended to only use the strict equals operator. In cases where types need to be coerced, it should be done explicitly and not left to the language's complicated coercion rules.

JavaScript Parser - Sometimes Intelligence causes problems...

JavaScript parser automatically inserts semicolon whenever   it encounters a   parse error due to missing semicolons.

var foo = function() {
} // parse error, semicolon expected
test()

Insertion happens, and the parser tries again.

var foo = function() {
}; // no error, parser continues
test()

The automatic insertion of semicolon is considered to be one of biggest design flaws in the language, as it can change the behavior of code.

How it works

The code below has no semicolons in it, so it is up to the parser to decide where to insert them.

(function(window, undefined) {
    function test(options) {
        writeToLog('testing semicolons...!')

        (options.list || []).forEach(function(i) {

        })

        options.value.test(
            'long string to pass here',
            'and another long string to pass'
        )

        return
        {
            foo: function() {}
        }
    }
    window.test = test
})(window)
(function(window) {
    window.someLibrary = {}
})(window)

Below is the result of the parser's "guessing" game.