Bloch's Builder Pattern / Updater
Comment on the builder pattern

I don't think that Joshua Bloch discovered any new version of the builder pattern. I suggest to follow the standard way and purposes from the GoF.

The purposes of the builder pattern are:


avoid having a lot of constructor parameters
provide a default and preserve consistency to be able to ALWAYS build an object
make the code fluently readable


I think here the pattern is not appropriate and not implemented in the way it should be. The Update()-method for example has nothing to do with any builder pattern.

A guess on the intention

As you mentioned a "repository" you are dealing with some kind of persistence context. In your implementation the build()-method will create a new object in the repository and the update()-method wil update an existing object in the repository so far I understand.

Proposal, creation and result

The design I would follow is a natural approach. 

If you want to create a new resource then you create a proposal object that contains data that may be considered during a creation process. The proposal object itself may have been constructed by a builder pattern. That depends on the purposes mentioned in the first place.

After that the proposal object is passed into the creation process. It will be validated and checked against internal system consistency. The creator object is well defined as the responsible for the creation of the wished object (SRP).

If no validation errors occured and it is not violating the systems consistency the object ist created AND persisted. The object may be internally (in the responsible object) constructed through the builder pattern. But that has nothing to do with persistence.

Proposal, update and result

The same with the update. The only difference is that you have an update proposal, an existing object to update and a responsible object that will to the update process.

Now it's getting interesting. The result of the update can be a versioned new object xor a cached old object. This depends on if you want to work with immutability or not. As you have an "id" I suggest to have the objects cached and mutable.

Nevertheless you have to override equals and hashcode in both scenarios. But be careful: two objects of any version are equal if their id is equal.

Conclusion


Do not make the builder pattern return mutable objects, always return new objects. The "builder" pattern is meant to "build" something not to update something
Only build transient, never involve persistence in the builder pattern
Have a proper design for CRUD-Operations for your persistent objects (business objects??) and well defined responsibilities
Distinguish between proposal, creator/updater/deleter and result


I am sorry, this is more a design issue of your problem domain than a pattern issue.