DapperLib / DapperLib/Dapper.Contrib

[Proposal] Ignoring properties for Insert or Update (Dapper.Contrib)

Open
#26 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C#
Stars
293
Forks
109
PR merge metrics
No merged PRs in 30d

Description

There are now Write and Computed attributes
Properties with those attributes are ignored in both Insert and Update methods.

We have use case now where we want some properties to be ignored on insert, but not on update, or vice-versa.

For example, DateCreated and DateModified.
On insert we want database to generate these dates. These columns have default getdate() constraints and after insert both DateCreated and DateModified will be the same.
DateCreated will obviously never change, but DateModified will change in application and be updated in database.

Now only DateCreated has Computed attribute which means we set DateModified in code and insert it into table. Since we set it to DateTime.Now, DateCreated is later than DateModified, which is not so good.

I think it would be convenient if there is a new attribute, someting like "IgnoreInsert" or similar, for ignoring properties for insert.
And maybe introduce new attribute, "IgnoreUpdate", and those two could maybe replace Write and Computed attributes after some time.

If there is interest, I myself could implement it and send pull request.
What do you think?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing Write and Computed attributes and the Insert and Update methods in Dapper.Contrib. Clarify whether separate IgnoreInsert and IgnoreUpdate attributes should replace or coexist with the current attributes, using the DateCreated and DateModified example as the acceptance case. Done means the intended per-operation property behavior is specified and implemented consistently.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
database
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
30/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.