DAO / repository: Good practice return value after insert / update

Question

Although probably a trivial question, I've always wondered about this.

Usually, after insertion into the db, it seems common practice to return the id of the business entity.

@Override
public Long createUser(UserEntity user) {
    em.merge(user); 
    em.flush(); 

    return user.getId(); 
}

Is there a convincing reason for returning the id instead of the business object reference itself?

Similarly, I've seen update return void, while it might just as well be an id / User.

If I were to write a DAO / Repository for others to use, what would be the advised return value (if any), and why?

merge leaves the passed entity detached, copies it's state to a managed entity and returns the managed entity. Returning the ID is useless: the caller already knows it since it passed it in the entity. What the caller needs is the created or updated managed entity. — JB Nizet, Jul 05 '16 at 11:43
Yep, the focus is here on the fact that the merge command returns the merged entity object. In my opinion that's the best practice. Just return the UserEntity Object that is returned by the merge command. The reason for this is that it is usually a good practice not to alter an object passed as a parameter. So you should probably expect the merge method not to alter the passed object. And always returning the same, unaltered object (or part of it), that was passed to your method might not be that purposeful. — Frank, Jul 06 '16 at 13:12

Andrew Tobilko · Accepted Answer · 2016-07-05T11:55:56.257

Why not return the whole instance if it has been created/updated successfully? The same what Spring Data do,

<S extends T> S save(S entity);
<S extends T> Iterable<S> save(Iterable<S> entities);

What have I to do if I need another part of the created/updated object, except id? (name, date for a User entity).
Why does id return if there are a few fields that exactly characterise an instance (a composite primary key)?

There is no difficulty to return the whole object (nothing is "overhead" here as mentioned by @Danny Fonk), but it may save much your time in the future.

score 1 · Answer 2 · answered Jul 05 '16 at 10:51

1

As per my experience , In insertion process return the id to the business entity is good practice because that id might be use full to continue the business process as it is newly entered record , moreover for the update process we fetch the entity before we update the record so that means we already got the id , so it's not necessary to return the id

answered Jul 05 '16 at 10:51

IZI_SL

135
1
5

Yes, but regarding the insert so does returning the business object ref if the id is set before returning. Agreed for the update part! – html_programmer Jul 05 '16 at 11:02

score 1 · Answer 3 · answered Jul 05 '16 at 10:53

I also think that returning the ID in general is good if not even best practive. Or you can also return the whole object but this is kinda "overhead" if you don't need to work with it anymore after creation.

At updating/altering an object in the database we always return the object itself or most likely just a boolean wether the update was succesfull or not since we already have the object.

score 1 · Answer 4 · answered Jul 05 '16 at 11:11

If you return the entity, the Client code would look like this:

MyEntity e = ...;
MyEntity created = dao.create(e);

but "e" and "created" are the same object. This can lead to confusion. You could argue that you can in future change the implementation of your create Method so that it really does return a different entity. I've seen this. I didn't like it. It was imho a terrible persistence design.

Now there is one Situation where I think returning the id is a good option: If you have a transaction boundary (REQUIRES_NEW) around your create Method. Passing ids instead of entities through transaction boundaries is not a bad thing.

Not sure why this would be the case. You can just reference the returned entity to the original one... Now I think about it, I assume you can even return void (although that wouldn't be very explicit), since what is passed is a copy of the reference and just set the id within the dao. — html_programmer, Jul 05 '16 at 11:20

DAO / repository: Good practice return value after insert / update

4 Answers4