how to handle a pattern i use that other may also want to use

[DennyFiguerres]

so i am making good progress overall.... and now i am thinking about what way might be the best way to handle this:

in all of my database tables i normally define a few standard columns that i want to handle in a standard manner. some of this might be done by extending entity framework but some this might be better to build into how OData works i think...

son in the table i will have two datetime offset columns 'Date Created', 'Last Changed' and two nvarchar columns 'Who Created', 'Who Changed'

when any get happens they should go out as part of the data ....

when a record is going to be posted / created i do not want the client to supply any of that data, i want OData and or Entity Framework to take care of that much like an identify / auto number ....

on update i do not want the client to supply that data and i want the server side OData and or Entity Framework to fill in the Change date and Who Changed.

now the "Who: i think has to be in the web api - i do not think that EF will have the http info on who the user is.
the dates i can see pssible ways to do them in ef.

but i want to see if anyone has any great ideas or related ways they do this.

[DennyFiguerres]

one thing i was thinking of to possibly support this might be an attribute that could be applied to the entity models.
something like RestierOverrideColumnData( OdataPost, OdataPatch, ODataDelete )

so that when for example the action is http patch or http put to update a record each item with that attribute would in effect remove the fields from the incoming patch data and the OData OnUpdating interceptor allows the server to provide updated data for the fields.

the idea is that i do not want the client to ever directly set the data in the 4 columns i use to keep track of record creation and update.
if the client loads any values i want to ignore them.... for the ones designated with the attribute.

the attribute could specify which methods to do this on (ODataPost, ODataPatch,ODataDelete) so its up to the author which ones to manage this way and for what actions.

having something like this integrated with Restier could help make building standard logic that much easier i think.

[robertmclaws]

None of that is necessary, what you are asking for is what Restier was specifically designed for.

You just need to use the OnUpdating{YourObject}Async(YourObject obj) methods to set the properties you need to as the data is coming in.

The legacy documentation we have here still (somewhat) applies: https://restier.readthedocs.io/en/latest/server/interceptors/. Here's a rough example:

        public virtual async Task OnInsertingYourEntityAsync(YourEntity entity)
        {
            ArgumentNullException.ThrowIfNull(entity, nameof(entity));

            entity.CreatedById = ClaimsPrincipal.Current.GetIdClaim();
            entity.DateCreated = DateTime.UtcNow;
            await Task.CompletedTask;
        }

[DennyFiguerres]

part of it i think is there; or perhaps i have missed some details....

i found and i am setting up the part where i can override the incoming data when i have a value to set.
but in the case of Update i have two pair of things to manage.

on an update i want to enforce the 'Who Updated' and 'Last Changed' like you are showing. that is good.
but on an update i do not want the client to put in a value in the 'Who Created' and 'Date Created'
i want to keep the values that are already in the data store.

i do not see a way (perhaps you can provide one ?) to say: if the clients Patch object has the two fields do not send them to EF, drop them.

for a new record i fill in all four in the server side logic. that one is already possible with what RESTIER does now.
but on update i see a problem.

and as others might want similar ability i was thinking of a way to tag what is special to allow for some generic way to handle it if we find a way to do it.

I hope I am explaining this clearly ?

is there a way in the current OnUpdate to
a) remove one or more fields / properties from the client's object before sending it to EF for update
or
b) replace the clients field values with the values from the data store for select fields before passing the data on to EF for update

methods a and b are both ways to get there but can i do one or both of them now ? can i get the current record from EF to do this kind of check ?
or can i change the clients object to clear the items so that the client can not modify them ?

[robertmclaws]

Yeah so the validation story in Restier is a little weak, and it's something I'm looking to fix in Restier 2.0.

Your Options

There are 3 ways you can handle this situation:

1. Make the setter on your audit properties internal. That way your code is the only one that can make the changes, and you can leverage the InternalsVisibleToAttribute to assist you in that effort. The practical effect of this would be to throw an error if someone attempted to change the value, but that error may end up being very low-level and the message might not be end-developer friendly.

2. You can pull the latest version of the record from the DB and validate it against the data coming in. You might have concurrency issues at scale doing this, so you may need to lock the record at the database level to evaluate the change.

3. You can use the ODataConventionModelBuilder to totally remove the Audit fields from the OData Metadata, which removes the data from the serialization pipeline. The end user will have no idea those properties even exist.

We chose Option 3 for BurnRate does it, however when we open up the API we will have to re-evaluate that decision.

Restier 2.0

The original design of Restier was to create a ChangeSet that contained the original and changed data. However that requires maintaining state and replicates a good portion of what the Entity Framework already does... plus the original team never finished that code, so I believe it remains unimplemented.

In Restier 2.0 I expect ChangeSet to be leveraged much more effectively to provide plug-in conventions for real-world situations like this, where you need to validate that Put | Post | Patch requests do not contain certain fields.

Restier 2.0 will be re-implemented from the ground up as a modern data-processing pipeline, so this scenario will be a first-class citizen in that version.

HTH!

[DennyFiguerres]

THANK YOU!
i will investigate the options you gave....
if i read them properly i think i will be looking at 1 and or 2.
it sounds like #3 will not work as i do want the get calls to be able to show the change data so that for example if i need to show details on an item then the creation and last change will be usefull in many cases , like say who created this ticket, or who changed this mailing address and things like that.
so i do want to have them "readable" on the client.