Update an obejct with out the nulls

mansour · **Joined:** Sat May 19, 2007 12:02 pm **Posts:** 19

I know what I need but I dont know how search for it or what is't called.
I need to update an object without over writing the values with NULLs. A simple example:
Let's say I have an record:

id=1
firstName="John"
lastName="Smith"

and this object is a persistence object. Then from my UI layer I got an object like this

id=1
firstName="Tom"
lastName=null;

and I need to update the first one in the DB without using the null value of the lastName field. So the final record in the DB should be:

id=1
firstName="Tom"
lastName="Smith"

How do I achieve this? How do I update only the non null values ?
I don't want to iterate and check for non nulls. I have a very big objects !

batmat · **Posted:** Sat Jun 16, 2007 6:00 pm

I guess you won't find anything specificly related to hibernate to deal with your problem. You will just have to choose between classical strategies.

When you persist yor object, is its Session still open? If so, maybe you could try and find a hack ('cause I'm not sure there's some standard use case for you) using the dirty information to know what changed...

Why don't you just put some business logic inside your entity, something like :

Code:

public class Person{
  String firstName;
  String name;
  public void setFirstName(String fName)
  {
    if(this.firstName == null )
    {
      this.firstName = fName;
    }
    else
    {
       //Here you could even throw an exception, maybe log a warning 
       //or whatever you want...
    }
  }
...
// and so on
}

mansour · **Joined:** Sat May 19, 2007 12:02 pm **Posts:** 19

Thank you batmat for you help. In fact this never came to mind and it possible. However, I am not sure if it's proper to put business logic in the Entity class. DO you have any refrence for some thing like this. I have choosen not to include business logic in the Entity even though I know it will ease many of my tasks. For example some thing like this

Code:

public class MyEntity{
..
public float getTotal()
{
    return untiCount * unitPrice;
}

and I never thought about some thing like what you did. For exmaple:

Code:

public void setFirstName(String firstName){
if ( firstName != null)
this.firstName = firstName;
}

I may end up doing this. However, do you have any link for a design pattern that shows what's the trade off of using simple business logic in the transfer Objects ?

batmat · **Posted:** Sun Jun 17, 2007 8:27 am

Well, at least putting no business logic at all in an object is a general object anti-pattern.

Moreover, in the Java Persistence with Hibernate book, for example, it's said that you should not program thinking about the fact you'll map your object with Hibernate.

Doing things in the methods Hibernate's gonna call can sometimes be a problem, but I don't think it will in your case.

In you want to be sure to not encounter any problem, you could for example put access="field" on the mapped property. This way, Hibernate will never encounter any "set" problem since it will directly access field. The method will then be only used by your code.

An intermediate method could be to add another setter used in your code an putting the one used by Hibernate protected.

hoeft · **Posted:** Sun Jun 17, 2007 12:11 pm

One question:
Your UI gets the fully initialized entity right? For example:
id=1
firstName="John"
lastName="Smith"

Then, the someone changed the first name. Hence the firstName attribute is changed. All the other attribute, which aren't changed, are set to null. So the resulting entity is:
id=1
firstName="Tom"
lastName=null;

If the UI didn't alter the lastName, you wouldn't have any problems. I think this would be the best solution. I don't see why the UI should set the not changed attributes to null. What is the sense of it?

However, If you can't change the behaviour of your UI and you don't want to compare the object which you get from the ui with the record in the database, I suggest that you take the sollution posted above by batman. If you implement his sollution which aspects (with aspectj for example) you mustn't implement the bevaviour in each entity and for each property:

Code:

public aspect DontSetNullPropertiesAspect {
//all setter Methodes of all my entities
pointcut allSetter(Object attribute):
execution(* my.entity.package..*.set*(*)) && args(attribute);

Object around(Object attribute) : allSetter(attribute) {
       if (attribute != null) {
           //set the attribute
           proceed(attribute);
       }
       return null;
}}

Code:

public class Person{ 
  String firstName; 
  String name; 
  public void setFirstName(String fName) 
  { 
      //the null check is done by the aspect
      this.firstName = fName;  
  } 
... 
// and so on 
} 

If you implement the behaviour with an aspect, your entity code won't be polluted, you'll have fewer code, it will apply for all your entities and it will be much more flexible. If you don't won't this behaviour in future (for example because you changed the behaviour of the UI), you will only have to delete the aspect and mustn't alter your entities.

One good bool about aspects: AspectJ in Action.

Hoeft