DapperLib / DapperLib/DapperAOT

Suggestion: db schema as "additional file"; apply validation

Open
#42 3 comments 3 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
C#
Stars
472
Forks
43
Avg merge
1d 4h
Merged PRs (30d)
18

Description

context: https://twitter.com/IanStockport/status/1702313925810024716

imagine a "dotnet tool":

dapper schema {conn-key} 

which:

  • resolved dev-time connection-key conn-key
  • connected to the database
  • probed the server-kind
  • dumped the schema to a file such as dbschema.txt
  • optional: find the csproj, check the additional file exists; if not, add it

Where dbschema.txt could be something like (is there prior art here? plain text?):

(note on order: objects are invariant alphabetical; columns/parameters/etc are positional)

default schema dbo
server version 16.0.1000.6

table dbo.Foo
column Id int notnull identity readonly
column Name string
column Label string computed readonly

table someSchema.Bar
column Id int notnull identity readonly

view someView
column Id notnull null
...

we would then load the dbschema.txt and use it to validate commands at build time, without needing constant SQL access. Schema should be implied via "default schema" when omitted.

Possible checks:

  • object exists
  • column exists (including views and functions)
  • capitalization
  • appropriate data types
  • treat views as immutable
  • don't allow update/insert to readonly columns
  • correct parameters on functions
  • correct function kind (scalar vs tabular UDF)
  • system functions vs server version
  • stored procedure parameters (columns are probably a stretch, unless we get the sp_helptext-etc source and parse that too?)
  • server version syntax rules (currently we always assume "latest")

Rewriting the db schema would be a case of re-running the tool, with the changes visible in source control.

Note: advanced SQL analysis is currently limited to SQL Server; we should probably at least not assume that when connecting (use the provider model), but... whatever works.

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

No files or tests are identified. Start by reviewing the proposed dapper schema {conn-key} dotnet-tool flow, the dbschema.txt format, and the existing SQL Server analysis/provider boundary; done would require an agreed scope for schema snapshots and provider-aware build-time validation.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, sql
Domain
build-system, databases, tooling
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
20/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.