• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

How to implement DAO update method

 
Maciej Olborski
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I am working on an application and I have been stuck for few days on implementing complete DAO for my User model. After a lot of trying I managed to get everything working except the update method for User.

That is my interface:


That is my DAO Implementation:


I have also tried to use only update(User user) and getting id through User object though the outcome was the same.

Here is my User model:


And here is my main class:


My expected output is:
User with following details was saved in DB: accountType Student cardId S1452512 eMail email@test.com firstName Test id 0 joinDate 03-03-2015 lastName LastName location GCU password password1 phoneNumber 07714862101
User logged in.
accountType Student cardId S1452512 eMail email@test.com firstName Test id 1 joinDate 03-03-2015 lastName LastName location GCU password password1 phoneNumber 07714862101
Firstname: Test Lastname: LastName
User with id 1 was updated in DB with following details: accountType Student cardId S1452512 eMail email@test.com firstName Test id 0 joinDate 03-03-2015 lastName LastName location GCU password password2 phoneNumber 07714862101
Password: password2
User with id: 1 was sucesfully deleted from DB.
Users database was truncated.

Given output is:
User with following details was saved in DB: accountType Student cardId S1452512 eMail email@test.com firstName Test id 0 joinDate 03-03-2015 lastName LastName location GCU password password1 phoneNumber 07714862101
User logged in.
accountType Student cardId S1452512 eMail email@test.com firstName Test id 1 joinDate 03-03-2015 lastName LastName location GCU password password1 phoneNumber 07714862101
Firstname: Test Lastname: LastName
User with id 0 was updated in DB with following details: accountType Student cardId S1452512 eMail email@test.com firstName Test id 0 joinDate 03-03-2015 lastName LastName location GCU password password2 phoneNumber 07714862101
Password: password1
User with id: 1 was sucesfully deleted from DB.
Users database was truncated.

I have highlighted the area of problem in output by using bold font.
I am helpless on this one. I know its a long one but I really need help on it or at least some guidance where to go from here.

Thanks in advance,
Mac
 
Dave Tolls
Ranch Hand
Posts: 2112
16
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Inside your update method, check how many rows were updated.
This is the value returned by the executeUpdate method.

Failing that, comment out everything in main() after the call to update and then check the database.
 
Maciej Olborski
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Okay, I have done what you mentioned. The output is 0 rows affected.

I understand that something is wrong in implementation and I have again looked through UPDATE SQL statement, the interface and the implementation of DAO and it all looks okey.

Any suggestions?

New DAOImpl:


I am assuming this is to do with the id in the output being 0 but not quite sure why that is a 0.

Mac
 
Dave Tolls
Ranch Hand
Posts: 2112
16
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maciej Olborski wrote:I am assuming this is to do with the id in the output being 0 but not quite sure why that is a 0.

Mac


Ah!
Code blindness on my part!

You're not setting that id when you read the user out of the database in the findById method, so it is still the default 0.
 
Maciej Olborski
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ahh, I've just noticed that too! Thank you a lot.

Do you think that my implementation of DAO seems okey for a desktop kind of application?

Maciej.
 
Dave Tolls
Ranch Hand
Posts: 2112
16
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So long as you're not planning on having multiple threads accessing the DAO at once it looks OK.
The only thing is the closing of resources on SQLExceptions.
You should either use the try-with-resources structure:

or close things like ResultSets and Statements in a finally block.
 
Maciej Olborski
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thank, you, big up for you!

Mac
 
Roel De Nijs
Sheriff
Posts: 10666
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Is there any reason why you opt for implementing DAO completely yourself and not using JPA with an ORM like Hibernate. And you could even throw Spring Data JPA into the mix.
 
Maciej Olborski
Greenhorn
Posts: 7
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Roel De Nijs wrote:Is there any reason why you opt for implementing DAO completely yourself and not using JPA with an ORM like Hibernate. And you could even throw Spring Data JPA into the mix.


Hi,

I am implementing DAO completely by myself because its an assigment and we've got to show off our code.

Mac
 
Roel De Nijs
Sheriff
Posts: 10666
144
AngularJS Chrome Eclipse IDE Hibernate Java jQuery MySQL Database Spring Tomcat Server
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maciej Olborski wrote:I am implementing DAO completely by myself because its an assigment and we've got to show off our code.

Fair enough!

Let me give you a few other tips/hints/suggestions:
  • you should definitely use automatic resource management (try-with-resources), because your current code could have resource leaks. Only possible if you are using Java 7 or later (mentioned by Dave Tolls as well)
  • use of prepared statements is really great
  • the conn instance variable must be private (encapsulation)
  • in authenticate: don't use Boolean, use boolean instead
  • getConnection and closeConnection should definitely not be part of the public API of UserDAO


  • If you really want to show off a really good class design, then getConnection and closeConnection should not even be part of the UserDAOImpl class. Why not? Because each class (and even each method) should have 1 specific purpose, the more specific this purpose, the better (in OO terms, that's called "high cohesion"). So your UserDAO should be responsible for the user management (reading, creating, updating, deleting,...) but not for connection management (creating, opening, closing,...). That's the responsibility of a connection factory class (or even better a connection pool).

    I could share all the required code, but it's your assignment so you have to do the coding I'll just give some pointers:

    1/ create a connection factory class
  • make it a singleton
  • in (private) constructor (it's a singleton) you already load the (mysql) driver
  • create a (private) createConnection method which gets a connection using url, user and password
  • create a (public) static getConnection method which invokes the createConnection method (on the single instance of this class)
  • One of the major benefits of introducing this class: you can reuse this class for other DAOs as well (code reuse).

    2/ rework your UserDAOImpl class
    If you have finished the 1st step, you have to redo every method of this class using this connection factory class and in the end you'll be able to remove the conn instance variable and all connection-related methods from this class. Yay! If you combine with using the Java 7 try-with-resources you'll get very clean code. Your code will end up looking like this:It will be slightly more difficult using a PreparedStatement, because you have to set its parameters (which can't be done in the try-with-resources block). But you could solve this using a private method. For example:And then you can call this method from the try-with-resources block.

    3/ rework your main method
    After you have finished the 2nd step, you'll have to fix a few compiler errors in this code And one other important OO rule: you should always program to an interface (or an abstract class). So you should write UserDAO userDAO = new UserDAOImpl(); instead.

    If you would encounter any problems while implementing any of these improvements, just let us now and we are happy to help you!

    Hope it helps!
    Kind regards,
    Roel
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic