session_privs and session_roles

So my friend was getting 'SYS.DBA_IND_COLUMNS table does not exit' while he was trying to run

desc dba_ind_coulmns

I was able to run the same query. So of course we are in the territory of authorizations. But how do I prove it?

Then can session_privs and session_roles into picture. For me the result was

SQL> select * from session_privs;

PRIVILEGE
----------------------------------------
CREATE SESSION
ALTER SESSION
SELECT ANY TABLE
SELECT ANY SEQUENCE

SQL> select * from session_roles;

ROLE
------------------------------
CONNECT
SELECT_CATALOG_ROLE
HS_ADMIN_ROLE
HS_ADMIN_SELECT_ROLE
HS_ADMIN_EXECUTE_ROLE
ADHOC

6 rows selected.

His user has more privilege but less roles.

For him the role was ADHOC_DML and no admin table roles and hence it was proved why he got 'table does not exist' error.

Another interesting table to know is v$session.

select SID,MACHINE,USERNAME from V$SESSION;

Git commands

> Log commits for a user since. Print in one line and with abbreviated commit

git log --committer=appandey --no-merges --since=2014-04-24 --pretty=oneline --abbrev-commit

> add all java files

git add \*.java

> Commit on someone else's behalf (same team)

git commit --author='author' -m '..'

fatal: No existing author found with 'author'

git commit --author='author <author@company.com>' -m '..'

e.g. git commit --author="amodpandey <amodpandey@gmail.com>" -m '...'

Did you know java TimeUnit class

I am not sure why Date din't do it, Calendar didn't do it and Apache DateUtils didn't do it?

Though every other product in every other company would need date diff !!!

I was introduced to TimeUnit through a retry wrapper class where I had to specify retry time using TimeUnit. So no longer we need a variable like private static final long numberOfSecondsInMinutes  = 60; :)

Date diff is a two liner with this class

1. Get the diff in millis
long diff = date1.getTime() - date2.getTime();

2. TimeUnit.MILLISECONDS.toDays(diff);

nJoy

Http Accept - 406

There are many HTTP headers which go unnoticed. Accept is one such header.

Accept is a way to tell the server what the client accepts. A server can smartly handle this.

e.g. Accept: application/xml to a service returns xml and Accept: application/json to same end point should return json.

Sometimes we have the server side code as to strictly say we support requests with Accept: application/json. I have seen ROR doing it when the return is of type JSON.

If the Web server detects that the data it wants to return is not acceptable to the client, it returns a header containing the 406 error code. 

I have observed the below behavior with our ROR set up

Success

Accept: application/xml,application/json
Accept: application/json,application/xml"
Accept: application/xml;q=0.9,application/json
Accept: */*

Failure (406)

Accept: */*, application/xml;
Accept: application/xml,*/*;
Accept: application/xml;q=0.9,*/*;
Accept: application/xml;

Note: I see */* is successful if Accept has only one entry with */*, else it expects application/json somewhere.

Chrome browser by default sends (may depend on browser and version)

1. Accept:
   text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8

So again it will fail. There are browser add ons which can help manipulate any of the HTTP headers for calls made through the browser. I have to use that for this call.

HTH someone, someday

The Orthodox: Java getter and setter

Let me start by saying, 'I hate it'. I always wrote it for the sake of writing it. Before making any decision I would like to bounce it with the community.

In the recent years most of us write Java classes that fall into one of these categories.

1. The so called POJO - Only attributes with getters and setters. Mostly used for serialization/de-serialization (to DB row, to JSON, to XML or any thing). - The carriers

2. The business processing classes where we tend not to have any instance variables. These are like the singleton instances doing the processing accepting/returning some POJO. - The performers

e.g.

class Customer {

public Integer addCustomer(MyCustomerBean bean) {
}

public MyCustomerBean get(Integer custid) {
}
}

So there is no instance variable dependency between two methods.

Further we get details from multiple such POJOs (e.g. MyAccountBean, MyCustomerBean) and put it into another POJO that is response to a service or UI call. These days annotation based mappers are quite famous, which would give you ResponseVO from  MyCustomerBean and MyAccountBean with a single line of code. I do remember how much tough life was without them (e.g. Castor for XML)

In none of these classes, ResponseVO, MyCustomerBean or MyAccountBean, the getters and setters do anything other than getting the variable and setting the variable. Is there any reason for which we keep doing it and blame it on to encapsulation??

Give me any good reason they are required for and yet they occupy 30-40% of your code! Thanks to eclipse to provide us with getters and setters generators. Just to add to the misery we add javadocs to such code ( again thanks to the auto javadoc generators).

Let's think whether they are required for our POJOs' or not? Can we have our POJO attributes public and lessen the pain.

Do I suggest having the Customer class with all the attributes and associated methods? Probably not. Today MyCustomerBean might a hibernate dependent bean and tomorrow it may be Toplink based. Let's give getters and setters a peaceful send off.

It may sound touche but YAGNI principle is really important to follow when the life of a code is too small to think about improvements, mostly it is re-writes.

What if I need to add a logic in my getters and setters won't help! :)

Code less that makes sense!
Happy Coding!

Third party calls (CORS), cookies and more...

1. Cookies set from the parent domain are by default not sent to the third party domain in xhr calls even if they from the common parent.

e.g. a.example.com and b.example.com

withCredential = true does the trick

2. Cookies set by the third party domain are not set on the client. The client ignores those headers.

Hibernate: OneToOne Mapping and fetch type

If a bean has a property that has mapping that is OneToOne mapping it is better to make the FetchType to EAGER.

EAGER FetchType will add to the main query.

LAZY makes the property to be loaded later, but is not the case with OneToOne mapping. After the bean is loaded all the OneToOne properties are loaded through a separate query if the FetchType is LAZY and will slow the loading.

Take away: OneToOne mapping FetchType.EAGER