Entity Updating strategy

Question

There is some discussion on my team about updating entity data and how best to approach it. This is a security framework and so here are some of the constraints and ideas.

1. every table in DB has a PK that is a guid, this is required for our multi-node clustering solution. The idea is that we don't want to expose this on an entity to a customer via an API because it could do two things,
   1. give them more info that needed for their job and giving hackers more information about the system.
   2. support nightmare is that a client hardcodes to this ID in some fashion and if we need to change our PK's clients are impacted.

solutions are to expose the natual key of the items like Role object with a unique Name, and Realm, together guarentee uniqueness however updating either of these values is the challenge, cause you need to specify the old and new values to update, or pass two objects in original and new object, so we can find the one to update. kind of messy,

another approach is to make an alternate key and have this exposed to the client they can use it all they want and we don't care cause it isn't tied to our PK.

it seems everyone these days just uses PK as ID for entities with no issues, not sure how to convince our team of veterns from the old timey programming days.

Another issue is how to support partial updates, issue is that you have entity with 10 properties, 4 collections, etc... with a name+realm combo and specify what property to update instead of pulling down whole object change 1 field, send back for update. I say lazy load the collections, but not sure if partial update makes sense.

thoughts?

thanks!

Answer 1

Use natural key if you need to expose id to client. It's not so easy to implement, but that's the correct way.

Could you provide little bit more details about those partial updates? I didn't get it. :/

Answer 2

My approach for a security framework would be like this:

• Give anything in the database an internal ID (identity column, sequence, whatever your database support. "native generated id column" in Hibernate speak). Eventually, you're going to need it and to retro-fit is a lot of work.

• If you need to hand an ID to the user, generate a random number, check that it hasn't been used already, connect it to an internal ID and then hand it to the user. Never hand out the internal ID and never use IDs that can be guessed by crackers.

As for partial updates, they only start to make sense if you have lots of objects with lots of attributes. For 10 attributes, I would say "premature optimization."

Answer 3

Using GUIDs on every table as a primary key sounds like asking for trouble. I have not seen this approach taken anywhere unless I am really misunderstanding you. Why not just issue a UID to every user and work with the UID?

This approach is most common across all companies. The UID is not PII so you are okay legally as was as from a security point of view.