Sunday, June 26, 2011

MySQL import and export

Here are few MySQL Queries/commands that i regularly use for exporting and importing MySQL data. This is for my reference, but just thought this might be useful for newbies.
MySQL Table Data Export and Import

To export the just table data please use the following query
SELECT * INTO OUTFILE 'data.txt' FIELDS TERMINATED BY ',' FROM mytable;
To import the csv file into table execute the following SQL Query.
LOAD DATA INFILE 'data.txt' INTO TABLE mytable FIELDS TERMINATED BY ',';

Copy the contents of one database to another

First, create the new database
create database db2;
Then, from the command-line, do the following to copy the contents from db1 to db2.
$ mysqldump -u root --password=pass db1 | mysql -u root --password=pass db2

MySQL Dump

To export the MySQL database into a dump file, please execute the following command
$ mysqldump -u root --password=pass db1 > dbdump.sql

Create MySQL User

Creating MySQL user and granting access
CREATE USER 'myuser'@'localhost' IDENTIFIED BY 'myuser';
GRANT ALL ON *.* TO 'myuser'@'localhost' IDENTIFIED BY 'myuser';

Tuesday, June 21, 2011

What is serialVersionUID?

Most people learn about serialVersionUID after they write their first serializable object (I know I did). You add ‘implements Serializable’ and in the next moment your IDE starts complaining… so what’s up?

Lets look at a simple example to see what meaning that variable has. In the example we will use the class SerializeMe shown below:

class SerializeMe implements Serializable {
private static final long serialVersionUID = 1L;

private int data;

public SerializeMe (int data) {
this.data = data;
}

public int getData() {
return data;
}
}

Field data represents some information stored in the class. Class implements the Serializable interface, so my IDE automatically offered me to declare the serialVersionUID field. Lets start with value 1 set there.

We will also need some class that will serialize and deserialize the SerializeMe class. Here it is:

public class UIDTester {
public static void main(String... strings) throws Exception {
File file = new File("out.ser");
FileOutputStream fos = new FileOutputStream(file);
ObjectOutputStream oos = new ObjectOutputStream(fos);

SerializeMe serializeMe = new SerializeMe(1);
oos.writeObject(serializeMe);
oos.close();

FileInputStream fis = new FileInputStream(file);
ObjectInputStream ois = new ObjectInputStream(fis);

SerializeMe dto = (SerializeMe) ois.readObject();
System.out.println("data : " + dto.getData());
ois.close();
}
}

This code will serialize an instance of class SerializeMe to a file and then deserialize it back. Now let’s run the main function! You should get output that says:
data : 1

It means that our object was properly serialized and deserialized. Note that the file “out.ser” was created on disk and it is still there even after the program finished. Let’s see if we can read that file once again, this time without creating it first. To do that, comment out lines from 4 to 9 in the UIDTester class:

public class UIDTester {
public static void main(String... strings) throws Exception {
File file = new File("out.ser");
//FileOutputStream fos = new FileOutputStream(file);
//ObjectOutputStream oos = new ObjectOutputStream(fos);

//SerializeMe serializeMe = new SerializeMe(1);
//oos.writeObject(serializeMe);
//oos.close();

FileInputStream fis = new FileInputStream(file);
ObjectInputStream ois = new ObjectInputStream(fis);

SerializeMe dto = (SerializeMe) ois.readObject();
System.out.println("data : " + dto.getData());
ois.close();
}
}

This way, the main method starts right away with reading the file from the disk and deserializing data stored in it. As the file is exactly the same and our class didn’t changed either, we should get exactly the same output:

data : 1

Now, let’s see what happens, when we change the serialVersionUID value and try to deserialize once again our file. Change the line 2 in the class SerializeMe so that serialVersionUID contains now 2 instead of 1:

private static final long serialVersionUID = 2L;

Now let’s run again our program (just like one step before, with commented out lines writing the file). We should get an exception like this:

Exception in thread "main" java.io.InvalidClassException:
SerializeMe; local class incompatible: stream classdesc
serialVersionUID = 1, local class serialVersionUID = 2

As you can see, this time the deserialization didn’t go well. ObjectInputStream complained about the serialVersionUID being changed. How does he know that it changed? If serialVersinUID is static, then it should not have been serialized in the first place, and there should be no information about the previous value 1 during the deserialization, right? Well, serialVersionUID is an exception to the rule that “static fields don’t get serialized”. ObjectOutputStream writes every time the value of serialVersionUID to the output stream. ObjectInputStream reads it back and if the value read from the stream does not agree with the serialVersionUID value in the current version of the class, then it throws the InvalidClassException. Moreover, if there is no serialVersionUID officially declared in the class to be serialized, compiler automatically adds it with a value generated based on the fields declared in the class.

So what is it for after all? Let’s suppose that there is some file storing a serialized object of some class A. The deserialization of that object does not necessarily have to occur exactly after serialization. It can occur after a few months or on a completely different JVM (i.e. sending an object through net using serialization). In both cases, there is a chance that the class declaration has changed between serialization and deserialization. It would be nice to have some kind of versioning system for every serializable class – and serialVersionUID does exactly that. It checks if the data read from the input stream is compatible with the current definition of the class.

If so, then why is it recommended to specify your own serialVersionUID ? It gives us simply more control. Default rules for generating serialVersionUID can be too strict in some cases. For example when the visibility of a field changes, the serialVersionUID changes too. Value generated automatically can differ between various Java implementations. There is a chance that some object serialized on one Java implementation will not deserialize on some other Java implementation, even if the class definition is exactly the same. Furthermore, sometimes you just want for some reason to forbid deserialization of old serialized objects, and in this case you just have to change the serialVersionUID.

Now that you know that specifying your own serialVersionUID is recommended, you might tend to write it once for every serializable class ( or have it generated by the IDE ) and forget about it. WRONG !!! If you write it once and don’t take care to update it when necessary, you loose all the merits of serialVersionUID. All your classes will get deserialized without exceptions even when using outdated data. What you should do is to change serialVersionUID (for example increase it by 1 or make your IDE generate automatically a new value) every time there is some change in the definition of data stored in the class. For example if you change data types, variable names or add new data – hence every time you want to have ‘backward incompatibility’ for deserialization.

Sunday, June 19, 2011

session tracking techniques in java

Here we do share session tracking techniques in java

What is a session?
seesion is a scope of accessing a client state in series of continuous request and response with in a browser window.

Why should a session be maintained?
When there is a series of continuous request and response from a same client to a server, the server cannot identify from which client it is getting requests. Because HTTP is a stateless protocol.

When there is a need to maintain the conversational state, session tracking is needed. For example, in a shopping cart application a client keeps on adding items into his cart using multiple requests. When every request is made, the server should identify in which client’s cart the item is to be added. So in this scenario, there is a certain need for session tracking.

Solution is, when a client makes a request it should introduce itself by providing unique identifier every time. There are five different methods to achieve this.
Session tracking methods:

User authorization
Hidden fields
URL rewriting
Cookies
Session tracking API

The first four methods are traditionally used for session tracking in all the server-side technologies. The session tracking API method is provided by the underlying technology (java servlet or PHP or likewise). Session tracking API is built on top of the first four methods.

1. User Authorization
Users can be authorized to use the web application in different ways. Basic concept is that the user will provide username and password to login to the application. Based on that the user can be identified and the session can be maintained.

2. Hidden Fields
<input name="”technology”" type="”hidden”" value="”servlet”" />
Hidden fields like the above can be inserted in the webpages and information can be sent to the server for session tracking. These fields are not visible directly to the user, but can be viewed using view source option from the browsers. This type doesn’t need any special configuration from the browser of server and by default available to use for session tracking. This cannot be used for session tracking when the conversation included static resources lik html pages.
3. URL Rewriting
Original URL: http://server:port/servlet/ServletName
Rewritten URL: http://server:port/servlet/ServletName?sessionid=7456

and

encodeURL
String encodeURL(String url)
Encodes the specified URL by including the session ID in it, or, if encoding is not needed, returns the URL unchanged. The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL. For example, if the browser supports cookies, or session tracking is turned off, URL encoding is unnecessary.

For robust session tracking, all URLs emitted by a servlet should be run through this method. Otherwise, URL rewriting cannot be used with browsers which do not support cookies.

Parameters:
url - the url to be encoded.
Returns:
the encoded URL if encoding is needed; the unchanged URL otherwise.

encodeRedirectURL
String encodeRedirectURL(String url)

Encodes the specified URL for use in the sendRedirect method or, if encoding is not needed, returns the URL unchanged. The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL. Because the rules for making this determination can differ from those used to decide whether to encode a normal link, this method is separated from the encodeURL method.

All URLs sent to the HttpServletResponse.sendRedirect method should be run through this method. Otherwise, URL rewriting cannot be used with browsers which do not support cookies.

Parameters:
url - the url to be encoded.
Returns:
the encoded URL if encoding is needed; the unchanged URL otherwise.

When a request is made, additional parameter is appended with the url. In general added additional parameter will be sessionid or sometimes the userid. It will suffice to track the session. This type of session tracking doesn’t need any special support from the browser. Disadvantage is, implementing this type of session tracking is tedious. We need to keep track of the parameter as a chain link until the conversation completes and also should make sure that, the parameter doesn’t clash with other application parameters.

and

String contextPath = request.getContextPath();
String userURL = contextPath + "/default.jsp?name="+userName;
String encodedUrl = response.encodeURL(userURL);
String encodedRedirectURL = response.encodeRedirectURL(userURL);
------
4. Cookies

Cookies are the mostly used technology for session tracking. Cookie is a key value pair of information, sent by the server to the browser. This should be saved by the browser in its space in the client computer. Whenever the browser sends a request to that server it sends the cookie alogwith it. Then the server can identify the client using the cookie.
In java, following is the source code snippet to create a cookie:

// creating a cookie
Cookie user = new Cookie("userName","Sreerama");
response.addCookie(user);
// retriving a cookie
Cookie [] userArray = request.getCookies();
for(Cookie user : userArray){
System.out.println(user.getName());
}


Session tracking is easy to implement and maintain using the cookies. Disadvantage is that, the users can opt to disable cookies using their browser preferences. In such case, the browser will not save the cookie at client computer and session tracking fails.

5. Session tracking API
Session tracking API is built on top of the first four methods. This is inorder to help the developer to minimize the overhead of session tracking. This type of session tracking is provided by the underlying technology. Lets take the java servlet example. Then, the servlet container manages the session tracking task and the user need not do it explicitly using the java servlets. This is the best of all methods, because all the management and errors related to session tracking will be taken care of by the container itself.Every client of the server will be mapped with a javax.servlet.http.HttpSession object. Java servlets can use the session object to store and retrieve java objects across the session. Session tracking is at the best when it is implemented using session tracking api.

// create a session
HttpSession ses = request.getSession(true); // arg- true/false
ses.setAttribute("user",UserObj);
// retrieve a session
HttpSession ses = request.getSession();
User user = (User)ses.getAttribute("user");
it depends on the browser preferences. the servlet tries to set cookies but if they are disabled in browser it moves to session tracking stuff with urlencoding.
// cookies and url rewrite
request.isRequestedSessionIdFromCookie();
request.isRequestedSessionIdFromURL();

simple Session Tracker

Here we share, how to track a user login as session in a simple way.

Detailed usage of Comparable and Comparator

Here we do share about Detailed usage of Comparable and Comparator.

-first we do try to understand Detailed usage of Comparable.

// Employee.java

package com.comparable;

public class Employee implements Comparable, Serializable {

private int eNo;
private String eName;
private float eSal;

public Employee() {
super();
}

public Employee(int eNo, String eName, float eSal) {
super();
this.eNo = eNo;
this.eName = eName;
this.eSal = eSal;
}

@Override
public int hashCode() {
System.out.println("-hashCode()- : " + this.hashCode());
final int prime = 31;
int result = 1;
result = prime * result + ((eName == null) ? 0 : eName.hashCode());
result = prime * result + eNo;
result = prime * result + Float.floatToIntBits(eSal);
return result;
}

@Override
public boolean equals(Object obj) {
System.out.println("-equals(obj)-: " + obj.toString());
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
Employee other = (Employee) obj;
if (eName == null) {
if (other.eName != null)
return false;
} else if (!eName.equals(other.eName))
return false;
if (eNo != other.eNo)
return false;
if (Float.floatToIntBits(eSal) != Float.floatToIntBits(other.eSal))
return false;
return true;
}

public int geteNo() {
return eNo;
}

public String geteName() {
return eName;
}

public float geteSal() {
return eSal;
}

@Override
public int compareTo(Employee emp) {
int comp = 0;
if ((comp = this.geteName().compareTo(emp.geteName())) != 0) {
} else {
if ((comp = Float.floatToIntBits(this.geteSal())
- Float.floatToIntBits(emp.geteSal())) != 0) {
} else {
comp = this.geteNo() - emp.geteNo();
}
}
return comp;
}
}
//EmpComparable.java
package com.comparable;

/*
* To be able to use the Comparable interface, the class of the objects
* in the collection has to implement that interface.
* You might have for example a List of objects from a class
* that you don't control yourself - for example,
* a class that comes from some third-party library.
* You can't make that class implement Comparable easily
* (it would mean you'd have to change the source code of
* the third-party library, which is normally not a good idea).
* To be able to sort the List anyway, you can implement your own Comparator
* and pass that to for example
* Collections.sort(list, comparator);.
* Your Comparator object can be separate from the objects that are in the List.
*/
import java.util.ArrayList;
import java.util.Collections;


public class EmpComparable {

/**
* @param args
*/
public static void main(String[] args) {

ArrayList empList = EmpComparable.getEmployees();

EmpComparable.EmpListIterate(empList);

}

public static ArrayList getEmployees() {

ArrayList empList = new ArrayList();
empList.add(new Employee(1, "Sreerama", 50000.0f));
empList.add(new Employee(2, "Seetha", 45000.0f));
empList.add(new Employee(8, "Lakshmana", 40000.0f));
empList.add(new Employee(4, "Bharatha", 30000.0f));
empList.add(new Employee(5, "Sethrugna", 20000.0f));
empList.add(new Employee(7, "Hanuma", 10000.0f));
empList.add(new Employee(6, "Hanuma", 15000.0f));
empList.add(new Employee(3, "Lakshmana", 40000.0f));

/*
* perform the sorting on given object; NOTE - no return type.
* we cont perform reverse sorting by using comparable
*/
Collections.sort(empList);

return empList;
}

public static void EmpListIterate(ArrayList empList) {

System.out.println("EmpNo" + "\t\t" + "EmpName" + "\t\t\t" + "EmpSal");
System.out.println("-----" + "\t\t" + "-------" + "\t\t\t" + "------");
// no need of Iterator here, we just go for display employees.
for (Employee emp : empList) {
System.out.println(emp.geteNo() + "\t\t" + emp.geteName() + "\t\t"
+ emp.geteSal());
}


}

}
output:
-------

---------------------------------
-Second, we do try to understand Detailed usage of Comparator.

//Employee.java
package com.comparator;

public class Employee implements Serializable {

private int eNo;
private String eName;
private float eSal;


public Employee() {
super();
}

public Employee(int eNo, String eName, float eSal) {
super();
this.eNo = eNo;
this.eName = eName;
this.eSal = eSal;
}

@Override
public int hashCode() {
System.out.println("-hashCode()- : " + this.hashCode());
final int prime = 31;
int result = 1;
result = prime * result + ((eName == null) ? 0 : eName.hashCode());
result = prime * result + eNo;
result = prime * result + Float.floatToIntBits(eSal);
return result;
}

@Override
public boolean equals(Object obj) {
System.out.println("-equals(obj)-: " + obj.toString());
if (this == obj)
return true;
if (obj == null)
return false;
if (getClass() != obj.getClass())
return false;
Employee other = (Employee) obj;
if (eName == null) {
if (other.eName != null)
return false;
} else if (!eName.equals(other.eName))
return false;
if (eNo != other.eNo)
return false;
if (Float.floatToIntBits(eSal) != Float.floatToIntBits(other.eSal))
return false;
return true;
}

public int geteNo() {
return eNo;
}

public String geteName() {
return eName;
}

public float geteSal() {
return eSal;
}
}
//EmpComparator.java
package com.comparator;

import java.util.ArrayList;
import java.util.Collections;
import java.util.Comparator;

import com.comparable.EmpComparable;
import com.comparable.Employee;

class EmpNameComparator implements Comparator {

@Override
public int compare(Employee emp1, Employee emp2) {
return emp1.geteName().compareTo(emp2.geteName());
}
}
class EmpNoComparator implements Comparator {

@Override
public int compare(Employee emp1, Employee emp2) {
return emp1.geteNo() &lt; emp2.geteNo() ? -1 : (emp1.geteNo() &lt; emp2
.geteNo()) ? 0 : 1;
}
}
class EmpSalComparator implements Comparator {

@Override
public int compare(Employee emp1, Employee emp2) {
return Float.floatToIntBits(emp1.geteSal()) &lt; Float.floatToIntBits(emp2
.geteSal()) ? -1
: (Float.floatToIntBits(emp1.geteSal()) &lt; Float
.floatToIntBits(emp2.geteSal())) ? 0 : 1;
}
}
public class EmpComparator {

public EmpComparator() {
// no code
}
public static Comparator CompareWith(String comp) {
System.out.println("-comp- " + comp);
Comparator compObj = null;
if (comp.equals("EmpName")) {
compObj = new EmpNameComparator();
} else if (comp.equals("EmpSal")) {
compObj = new EmpSalComparator();
} else {
compObj = new EmpNoComparator();
}
return compObj;
}
public static ArrayList showEmployees() {
ArrayList empList = new ArrayList();
empList.add(new Employee(1, "Sreerama", 50000.0f));
empList.add(new Employee(2, "Seetha", 45000.0f));
empList.add(new Employee(8, "Lakshmana", 40000.0f));
empList.add(new Employee(4, "Bharatha", 30000.0f));
empList.add(new Employee(5, "Sethrugna", 20000.0f));
empList.add(new Employee(7, "Hanuma", 10000.0f));
empList.add(new Employee(6, "Hanuma", 15000.0f));
empList.add(new Employee(3, "Lakshmana", 40000.0f));
// perform the sorting on given object; NOTE - no return type.
Collections.sort(empList, EmpComparator.CompareWith("EmpName"));
EmpComparable.EmpListIterate(empList);
Collections.sort(empList, EmpComparator.CompareWith("EmpSal"));
EmpComparable.EmpListIterate(empList);
Collections.sort(empList, EmpComparator.CompareWith("default"));
EmpComparable.EmpListIterate(empList);
//Reverse sort is also possible.
Collections.sort(empList, Collections.reverseOrder(EmpComparator.CompareWith("default")));
EmpComparable.EmpListIterate(empList);
return empList;
}
public static void EmpListIterate(ArrayList empList) {

System.out.println("EmpNo" + "\t\t" + "EmpName" + "\t\t\t" + "EmpSal");
System.out.println("-----" + "\t\t" + "-------" + "\t\t\t" + "------");
// no need of Iterator here, we just go for display employees.
for (Employee emp : empList) {
System.out.println(emp.geteNo() + "\t\t" + emp.geteName() + "\t\t"
+ emp.geteSal());
}
}
public static void main(String[] args) {
ArrayList empList = EmpComparator.showEmployees();

}
}

output:
------

// In reverse order by EmpNo as default sort.