Milos Radovic wrote:I've tried to correct my code but I can't make it work. Can somebody help me?
Roel De Nijs wrote:
Did you try debugging your code? Do you know which line (and reference variable) is causing the NullPointerException to be thrown?
Dave Tolls wrote:Books has a conn instance declared as a member attribute. This looks like the instance of 'conn' that is being used in the insert() method. So, where is that variable initialised?
Milos Radovic wrote:I tried to fix this code but there is something wrong. Unfortunately don't know how to solve this.
Milos Radovic wrote:and the problem is fixed
Roel De Nijs wrote:
to avoid resource leaks you should always close your resources.
Milos Radovic wrote:at the end of the insert method to close the connection?
Milos Radovic wrote:I will now create separate project and try to apply all your suggestions.
Milos Radovic wrote:Well here it is
Roel De Nijs wrote:
That already looks so much better. Well done! Have a cow for all the effort you made to refactor your code.
Roel De Nijs wrote:
3/ Why do you have a cast to Connection in the create() method? The getConnection() already returns a Connection.
Milos Radovic wrote:
Roel De Nijs wrote:
3/ Why do you have a cast to Connection in the create() method? The getConnection() already returns a Connection.
If I'm right, you are referring to "(Connection)" in the line:
If I delete it the "(Connection)" from the line, my NetBeans shows an error and tells me that I should cast the "(Connection)" back.
Any idea how can I fix this?
Paul Clapham wrote:
That shouldn't be happening. It looks like you have imported some different "Connection" type. You didn't post your import statements, but look at them: you should be importing "java.sql.Connection". Sometimes Netbeans will pop up a dialog saying something like "Which of these Connection types would you like to import?" and if you choose the wrong one then this sort of thing can happen.
Milos Radovic wrote:You are right i have imported "com.mysql.jdbc.Connection;" instead of "java.sql.Connection;"
Milos Radovic wrote:Here is the final code:
Dave Tolls wrote:Since ID is an int of some sort (as shown by your INSERT code), then shouldn't it be treated as an int for your DELETE and UPDATE ones as well?
Roel De Nijs wrote:5/ And maybe you could have a few (private) class (static) variables (constants) with the different queries: e.g. DELETE_QUERY, INSERT_QUERY, and UPDATE_QUERY.
Milos Radovic wrote:Thanks for the help, I have learned so much
Dustin Ward wrote:What are the benefits of having these declared as private static queries instead of initialized inside of each method? I have many, many queries inside each DAO so should I do the same?
Roel De Nijs wrote:
Assuming these queries inside each DAO are all String literals, there is no real benefit of having these queries defined as class (static) final variables (constants) thanks to how Java handles String literals besides having all queries grouped together at the top of your DAO class.
Roel De Nijs wrote:
2/ in the update query you are still using one actual value (the headline) instead of a placeholder, so you can truely benefit from using prepared statements (I think it's the 2nd or 3rd time I have mentioned this issue)
Roel De Nijs wrote:
Dustin Ward wrote:What are the benefits of having these declared as private static queries instead of initialized inside of each method? I have many, many queries inside each DAO so should I do the same?
Assuming these queries inside each DAO are all String literals, there is no real benefit of having these queries defined as class (static) final variables (constants) thanks to how Java handles String literals besides having all queries grouped together at the top of your DAO class.
Dave Tolls wrote:
Roel De Nijs wrote:
Assuming these queries inside each DAO are all String literals, there is no real benefit of having these queries defined as class (static) final variables (constants) thanks to how Java handles String literals besides having all queries grouped together at the top of your DAO class.
That's the gain for me.
If there's a change in the table for whatever reason (usually in early development) then you have all the SQL in one spot, rather than sifting through the whole DAO.
It's not a huge gain, but it does help.
Roel De Nijs wrote:
Looks great! Have another cow for all refactoring effort!