Passion

Passion is a state of being drunk and the drink is not poison. #quotes #passion #drunk #quote

Protozoa

protozoa

Cycloptic Bird

Cycloptic bird

Just a Doodle

Just a Doodle

What is exactly happening when instantiating with ‘new’?

Let’s consider the following code:

class a {
    public $var1;
    function disp(){
        echo $this->var1;
        }    
    }

$obj1 = new a;
echo '<br />After instantiation into $obj1:<br />';    
xdebug_debug_zval('obj1');  

$obj1->var1 = "Hello ";
echo '<br /><br />After assigning "Hello" to  $obj->var1:<br />';
$obj1->disp();

echo "<br /><br />";  
xdebug_debug_zval('obj1');  
 

The output:

After instantiation into $obj1:
obj1: (refcount=1, is_ref=0)=class a { public $var1 = (refcount=2, is_ref=0)=NULL }

After assigning "Hello" to $obj->var1:
Hello

obj1: (refcount=1, is_ref=0)=class a { public $var1 = (refcount=1, is_ref=0)='Hello ' }
 

One by one:

After instantiation into $obj1:
obj1: (refcount=1, is_ref=0)=class a { public $var1 = (refcount=2, is_ref=0)=NULL }
 

Why does $obj1->var1 have refcount=2 when there is only one object of class a?

Is it because of how the new operator makes assignment? PHP does assignment with references. When instantiated with new, no symbol/variable name is associated with that instance. But, the class properties do have names. Is the recount=2 because of this?

If that is the case then a C.O.W (copy on write) has occurred with a shallow copy WRT the class instance. While the properties are still pointing to the zval’s of properties created during the instantiation using new.

Now,

After assigning "Hello" to $obj->var1:
Hello

obj1: (refcount=1, is_ref=0)=class a { public $var1 = (refcount=1, is_ref=0)='Hello ' }
 

So, when I assign a value to the property $obj1->var1 a new zval container for that property and hence the refcount=1?

Does this mean that the zval container created during instantiation using new still lives but cannot be accessed since there is no symbol / variable name associated with it?

Please note (from xdebug: Variable Display Features):
debug_zval_dump() is different from xdebug_debug_zval().

void xdebug_debug_zval( [string varname [, …]] )
 
    Displays information about a variable.
 
    This function displays structured information about one or more variables that includes its type, value and refcount information. Arrays are explored recursively with values. This function is implemented differently from PHP's debug_zval_dump() function in order to work around the problems that that function has because the variable itself is actually passed to the function. Xdebug’s version is better as it uses the variable name to lookup the variable in the internal symbol table and accesses all the properties directly without having to deal with actually passing a variable to a function. The result is that the information that this function returns is much more accurate than PHP’s own function for showing zval information.

The question was posted by me on StackOverflow. Sadly couldn’t find an answer. If anyone could point to better Documenation of xdebug most welcome.
If you want to follow the conversation, here is the link to the question:
http://stackoverflow.com/q/8668664/858515

PHP : Demystify Type Hinting and Default Parameters

Type Hinting as described in PHP manual

PHP 5 introduces Type Hinting. Functions are now able to force parameters to be objects (by specifying the name of the class in the function prototype) or arrays (since PHP 5.1). However, if NULL is used as the default parameter value, it will be allowed as an argument for any later call.

The above Means that:

Parameters which are Objects or Arrays can only be type hinted.
i.e.
Types (Scalar variables) integer, float, string or boolean & Types(non scalar) resource cannot be used in type hinting.

i.e.
The code in Code1 & Code2 are not allowed.

Code1:
function myfunc ( string $name = "myname") {  ...  }

Code2:
function myfunc ( int $age = 23) {  ...  }

Although the above will not generate any compile time error, It does give out a fatal error during runtime as.

Fatal error: Default value for parameters with a class type hint can only be NULL

This is because PHP would be treating string and int as class names.
To quote a valid example, lets say we have a class called myclass.
Then the code in code3 is allowed and right:

Code3:
function myfunc ( myclass $myobj){ ... }

The argument passed to function in code 3 must be an instance of ‘myclass’.

The final sentence which is:

if NULL is used as the default parameter value, it will be allowed as an argument for any later call.

if default parameters are to be used use with type hinting, it can only have NULL as the default value.

Code4:
function myfunc ( myclass $myobj = NULL){ ... }

The argument passed to function in code 4 can be an instance of ‘myclass’ or NULL.

Code5:
function myfunc ( array $myarray = NULL){ ... }

The argument passed to function in code 4 can be an array or NULL.

You cannot instantiate an object in the parameter part of the function declaration!
&
The following function would be wrong!

Code6:
function myfunc ( array $myarray = array('a', 'b', 'c', 'd'){ ... }

A workaround:

Code7:
function myfunc ( array $myarray = NULL){ 
if ($myarray === NULL) $myarray = array('a', 'b', 'c', 'd');
}

*find any mistakes? do feel free to point it out.

Thoughts

It’s not about what you are doing. Its about why you are doing what you are doing.

Mysql EXPLAIN output format:Explaining the EXPLAIN output: Part 1:

The EXPLAIN commands has the following 10 output columns (from:7.8.2. EXPLAIN Output Format)

ColumnMeaning
idThe SELECT identifier
select_typeThe SELECT type
tableThe table for output row
typeThe join type
possible_keysThe possible indexes to show
keyThe index actually chosen
key_lenThe length of chosen key
refThe columns compared to the index
rowsEstimate of rows to be examined
ExtraAdditional information

Lets start explaining each of these columns one by one with examples:

id

The SELECT identifier. This is the sequential number of the SELECT within the query.

EXPLAIN SELECT * FROM table1 WHERE name='name0' UNION SELECT * FROM table1 WHERE name='name1';

“The query above is a dumb query”.
*select_type will be explained later

The result of the query will have 3 rows:There will be 2 id’s generated:

1] id=1 for select * from table1 where name=’name0′ with
select_tye:PRIMARY, table:table1;

2] id=2 for select * from table1 where name=’name1′ with
select_tye:UNION, table:table1;

3] id=NULL. No sequential numbers will be generated here;
select_tye:UNION RESULT, table:;

select_type

SIMPLE

Simple SELECT (not using UNION or subqueries)

EXAMPLE QUER(Y|IES):
SELECT * FROM TABLE1;
SELECT * FROM TABLE1 WHERE COLUMN1='SOMESTRING';

PRIMARY

Outermost SELECT

EXAMPLE QUER(Y|IES):
SELECT * FROM table1 WHERE name='name0' UNION SELECT * FROM table1 WHERE name='name1';

SELECT * FROM table1 is the outer most select hence PRIMARY.

SELECT ID FROM (select * from TABLE1 where NAME='name0') p;

SELECT ID FROM is the outer most select hence PRIMARY.

UNOIN

Second or later SELECT statement in a UNION

EXAMPLE QUER(Y|IES):
SELECT * FROM table1 WHERE name='name0' UNION SELECT * FROM table1 WHERE name='name1';

SELECT * FROM table1 WHERE name=’name1′ is the second select in the above query with UNION hence select_type is UNION

SELECT * FROM table1 WHERE name='NAME0' UNION SELECT * FROM name WHERE name='NAME1' UNION SELECT * FROM table1 WHERE name='name2';

SELECT * FROM table1 WHERE name=’name1′ is the second select; SELECT * FROM table1 WHERE name=’name1′ is the later select; in the above query with UNION hence select_type for these 2 selects will be UNION

DEPENDENT UNION

Second or later SELECT statement in a UNION,dependent on outer query

EXAMPLE QUER(Y|IES):
SELECT t1.column_name,(SELECT t2.column_name FROM table2 AS t2 WHERE t2.name='NAME0' UNION SELECT column_name FROM table3 WHERE id=t1.id) FROM table1 AS t1 WHERE name='name1';


SELECT column_name FROM table3 WHERE id=t1.id has the select_type as DEPENDENT UNION as the where clause in it is dependent on a value from an outer query which is:SELECT t1.column_name,… FROM table1 AS t1 WHERE name=’name1′;

UNION RESULT

Result of a UNION.

Any query which has a UNION in it will have this row(extra) in its explain output with an id NULL and select_type as UNION RESULT

SUBQUERY

First SELECT in subquery

for more about SUBQUERY visit here:12.2.10. Subquery Syntax

EXAMPLE QUER(Y|IES):

SELECT t1.column_name,(SELECT t2.column_name FROM table2 AS t2 WHERE t2.name='NAME0') FROM table1 AS t1 WHERE t1.name='NAME0';


SELECT t2.column_name FROM table2 AS t2 WHERE t2.name=’NAME0′ is the sub query which is not dependant on any other query.

DEPEDENT SUBQUERY

First SELECT in subquery, dependent on outer query

EXAMPLE QUER(Y|IES):SELECT t1.column_name,(SELECT t2.column_name FROM table2 AS t2 WHERE t2.id=t1.id) FROM table1 AS t1 WHERE t1.name='name0';

SELECT t2.column_name FROM table2 AS t2 WHERE t2.id=t1.id has a where clause which is dependent on the outer query: SELECT t1.column_name,…FROM table1 AS t1 WHERE t1.name=’name0′; hence its select_type will be DEPENDENT SUBQUERY

DERIVED

Derived table SELECT (subquery in FROM clause)

EXAMPLE QUER(Y|IES):
SELECT id FROM (SELECT * FROM table1 WHERE name like 'abcd') AS t1;

SELECT * FROM table1 WHERE name like ‘abcd’ is a SUBQUERY which lies in the FROM clause hence has the select_type as DERIVED

UNCACHEABLE SUBQUERY

A subquery for which the result cannot be cached and must be re-evaluated for each row of the outer query

The EXAMPLE QUER(Y|IES)
SELECT t1.column_name,(SELECT t2.column_name FROM table2 AS t2 WHERE t2.name='name0' UNION SELECT t3.column_name FROM table3 AS t3 WHERE t3.id=t1.id ) FROM table1 AS t1 WHERE name='NAME0';

SELECT t2.column_name FROM table2 AS t2 WHERE t2.name=’name0′ will have the select_type as UNCACHEABLE SUBQUERY since its in conjunction in an UNION with SELECT t3.column_name FROM table3 AS t3 WHERE t3.id=t1.id which has a where clause dependent on the results from an outer query and have select_type as DEPENDENT UNION.

UNCACHEABLE UNION

The second or later select in a UNION that belongs to an uncacheable subquery(see UNCACHEABLE SUBQUERY)

SELECT t1.column_name,(SELECT t2.column_name FROM table2 AS t2 WHERE t2.id=t1.id UNION SELECT t3.column_name FROM table3 AS t3 WHERE t3.name='NAME0' ) FROM table1 AS t1 WHERE name='NAME0';

SELECT t3.column_name FROM table3 AS t3 WHERE t3.name=’NAME0′ will have its select_type as UNCACHEABLE UNION as it is the 2nd query in the UNION with the query: SELECT t2.column_name FROM table2 AS t2 WHERE t2.id=t1.id which has a where clause dependent on the results of an outer query hence its select_type being DEPENDENT SUBQUERY.

For more about query caching, read this: MySQL Query Cache

table

Displays the table name for that output row.

SELECT t1.column_name,(SELECT t2.column_name FROM table2 AS t2 WHERE t2.id=t1.id UNION SELECT t3.column_name FROM table3 WHERE name='NAME0' ) FROM table1 AS t1 WHERE name='NAME0';

The above code will the following table name listed
t1
t2
table3

*will be continued in the next part.
*find any mistakes? do feel free to point it out.

MySQL performance tuning: The ‘EXPLAIN’ command output: Access Types

EXPLAIN Output Format has the ‘type’ column which is poorly named: We would call it the access types:

Performance Tuning Best Practices for MySQL: http://www.youtube.com/watch?v=u70mkgDnDdU
and

• type: the “join type”
• Really, the access type: how MySQL will access the
rows to find results
• From worst to best
– ALL, index, range, ref, eq_ref, const, system, NULL

from EXPLAIN Demystified by Baron Schwartz Percona Inc.

What are these?

______________________________________________________________________

  'EXPLAIN' Join Types: (from: 7.8.2. EXPLAIN Output Format ) (the doc is for MySQL 5.6)
 ______________________________________________________________________

The type column of EXPLAIN output describes how tables are joined. The following list describes the join types, ordered from the best type to the worst:

• system

  The table has only one row (= system table). This is a special case of the constjoin type.

• const

  The table has at most one matching row, which is read at the start of the query. Because there is only one row, values from the column in this row can be regarded as constants by the rest of the optimizer. consttables are very fast because they are read only once.const is used when you compare all parts of a PRIMARY KEY or UNIQUE index to constant values. In the following queries, tbl_name can be used as a consttable:

  SELECT * FROM tbl_name WHERE primary_key=1;
  
  SELECT * FROM tbl_name
    WHERE primary_key_part1=1 AND primary_key_part2=2;

• eq_ref


  One row is read from this table for each combination of rows from the previous tables. Other than the system and const types, this is the best possible join type. It is used when all parts of an index are used by the join and the index is a PRIMARY KEY or UNIQUE NOT NULLindex.eq_ref can be used for indexed columns that are compared using the = operator. The comparison value can be a constant or an expression that uses columns from tables that are read before this table. In the following examples, MySQL can use an eq_ref join to process ref_table:

  SELECT * FROM ref_table,other_table
    WHERE ref_table.key_column=other_table.column;
  
  SELECT * FROM ref_table,other_table
    WHERE ref_table.key_column_part1=other_table.column
    AND ref_table.key_column_part2=1;

• ref

  All rows with matching index values are read from this table for each combination of rows from the previous tables. ref is used if the join uses only a leftmost prefix of the key or if the key is not a PRIMARY KEY or UNIQUEindex (in other words, if the join cannot select a single row based on the key value). If the key that is used matches only a few rows, this is a good join type.ref can be used for indexed columns that are compared using the = or <=> operator. In the following examples, MySQL can use a ref join to process ref_table:

  SELECT * FROM ref_table WHERE key_column=expr;

  SELECT * FROM ref_table,other_table WHERE ref_table.key_column=other_table.column; SELECT * FROM ref_table,other_table WHERE ref_table.key_column_part1=other_table.column AND ref_table.key_column_part2=1;

• fulltext

  The join is performed using a FULLTEXT index.

• ref_or_null

  This join type is like ref, but with the addition that MySQL does an extra search for rows that contain NULL values. This join type optimization is used most often in resolving subqueries. In the following examples, MySQL can use a ref_or_null join to process ref_table:

  SELECT * FROM ref_table
    WHERE key_column=expr OR key_column IS NULL;

  See Section 7.13.5, “IS NULL Optimization”

• index_merge


  This join type indicates that the Index Merge optimization is used. In this case, the key column in the output row contains a list of indexes used, and key_len contains a list of the longest key parts for the indexes used. For more information, see Section 7.13.2, “Index Merge Optimization”.

• unique_subquery

  This type replaces ref for some INsubqueries of the following form:

  value IN (SELECT primary_key FROM single_table WHERE some_expr)

  unique_subquery is just an index lookup function that replaces the subquery completely for better efficiency.

• index_subquery


  This join type is similar to unique_subquery. It replaces INsubqueries, but it works for nonunique indexes in subqueries of the following form:

  value IN (SELECT key_column FROM single_table WHERE some_expr)

• range

  Only rows that are in a given range are retrieved, using an index to select the rows. The key column in the output row indicates which index is used. The key_len contains the longest key part that was used. The ref column is NULLfor this type.range can be used when a key column is compared to a constant using any of the =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, or IN()operators:

  SELECT * FROM tbl_name
    WHERE key_column = 10;
  
  SELECT * FROM tbl_name
    WHERE key_column BETWEEN 10 and 20;
  
  SELECT * FROM tbl_name
    WHERE key_column IN (10,20,30);
  
  SELECT * FROM tbl_name
    WHERE key_part1 = 10 AND key_part2 IN (10,20,30);

• index


  This join type is the same as ALL, except that only the index tree is scanned. This usually is faster than ALLbecause the index file usually is smaller than the data file.MySQL can use this join type when the query uses only columns that are part of a single index.

• ALL


  A full table scan is done for each combination of rows from the previous tables. This is normally not good if the table is the first table not marked const, and usually very bad in all other cases. Normally, you can avoid ALL by adding indexes that enable row retrieval from the table based on constant values or column values from earlier tables.

Mysql 5.6 on Fedora. Innodb with Full Text Search.

Currently I am using  Fedora release 15 (Lovelock):
Downloaded server from (I have a 64 bit workstation):
mysql-5.6.4-labs-innodb-fts-linux2.6-x86_64
from
http://labs.mysql.com/

mysql-5.6.4-labs-innodb-fts-linux2.6-x86_64
mysql-5.6.3-labs-innodb-features-linux2.6-x86_64

Difference between the above 2 packages:
The package mysql-5.6-labs-innodb-features on MySQL Labs consists of a set of InnoDB new features since MySQL 5.6.2 milestone release, except InnoDB full-text search. Where as, mysql-5.6-labs-innodb-fts on MySQL Labs consists of a set of InnoDB new features since MySQL 5.6.2 milestone release, including InnoDB full-text search.
courtesy:http://blogs.innodb.com/wp/2011/07/innodb-2011-summer-labs-releases/

Installed the client from MySQL-5.6.3_m6-1.linux2.6.x86_64 (since I had already downloaded this):

from http://dev.mysql.com/downloads/mysql/#downloads from tab development releases.

Followed the installation “HOW To” from here: http://dev.mysql.com/doc/refman/5.6/en/binary-installation.html
Got installed fine.

Although I still have to start the server by navigating to:
/etc/init.d
&
./mysql.server start

I still have to add it to services and automate server start during system start-up.