entity class constructor

[K. Tsang]

I'm using Netbeans IDE and in Netbeans, when I generate an entity class it generates a default constuctor, constructor with primary key and constructor with all fields. Say the entity class is Account:

 
    public Account(){ }
 
    public Account(String email){ this.email = email;  }
 
    public Account(String email, String password){
        this.email = email;
        this.password = password;
    }
 

Now if I instantiate the Account class with new Account(email), the password field will ultimately be null. So when do people use this particular form of constructor or is it simply useless? This is because if I do that, and then do getPassword() method, I get NullPointerException.

But if I query the result from database shouldn't the password field in the entity class set the the password field of that particular row?

  Account acct = (Account) em.createNamedQuery("Account.findByEmail").setParameter("email", mail).getSingleResult();  

Eg After I execute the above line, the acct variable should populate email and password instance vars in the entity class right??

[Marco Ehrentreich]

Hi,

I think you're seeing the result of the standard auto completion feature of NetBeans. If you use auto completion and have no constructor the completion mechanism proposes (amongst others) to build a constructor which initializes all current members of the class.

For the the Java persistence API respectively entity beans to work you just need a public or protected default constructor with no arguments. If you query such an object from the database (via entity manager or EJBQL) an new object is created with the default constructor and the corresponding fields get initialized directly or via the getter methods with the values accordingly to the contents in the database.

How useful such constructor are for other purposes depends of course on your needs. If you don't have a good default value for a member variable at the time you create an object then it probably doesn't make sense to include it as a parameter in a constructor.

Marco
[ June 02, 2008: Message edited by: Marco Ehrentreich ]

[K. Tsang]

Thanks for the reply. So my udnerstanding is the query return an object that instantiates the object's default constuctor. This would mean the same as I physically calling new <class>() then calling each setter method to set the variables. If this is the case, why bother using the query in the first place?

[Marco Ehrentreich]

Because it's easier to use EJBQL? Of course you don't have to use EJBQL or the Java persistence API. They do nothing you couldn't do "by hand". You could use annoying SQL statements all over your code to get the data from a database, instantiate an empty entity object and set its properties via setter methods.

One advantages of EJBQL over plain SQL statements is that it's is type-safe and automatically returns the correct types of objects which it determines from the annotations to your entity classes.
It's easier to use because you don't have to worry about actual table or column names in your database. In EJBQL you use class and properties names!
It can maintain not only single types of entities but also entity relationships. So if you have for example a one-to-many relationship a query doesn't only fetch the "one" side but it can also get the corresponding objects on the "many" side an link them to the "one" side.

Anyway most times it's not even necessary to formulate an EJBQL query because you can often get away with the ordinary methods of the EntityManager like persist(), remove(), find() etc. So you have to look at the Java persistence API as a whole framework and not only the queries. It handles database connections, it can (depending on the persistence provider) automatically create or delete your database schemata, you can easily change the underlying database system, you get transaction handling from it, you can create almost any mapping to existing databases with annotations, relationships and inheritance are automatically mapped to corresponding tables and you are even free to use native SQL statements where really necessary.

I hope this were some convincing points. Perhaps you should look at the Java persistence API in general and not only focus on EJBQL, then the advantages may become more obvious.

Marco