Support for snake_case column names

[mnebes]

Hi,

the preferred naming convention for postgres databases calls for table/column names to be using snake_case, since Dapper allows reading such columns with Dapper.DefaultTypeMap.MatchNamesWithUnderscores <- true could we also somehow add an option for names in record fields to be interpreted as snake_case?

Example:

let r = {
    Id = Guid.NewGuid()
    FirstName = "Works"
    LastName = "Great"
    DateOfBirth = DateTime.Today
    Position = 1
}

let sql, values =
    insert {
        table "person"
        value r
    } |> Deconstructor.insert

printfn "%s" sql 
// INSERT INTO person (id, first_name, last_name, position, date_of_birth) 
// VALUES (@Id0, @FirstName0, @LastName0, @Position0, @DateOfBirth0)"

[Dzoukr]

Hi Michal,

I need to think about this one because then we would be pretty close to functionality I did not add on purpose (for clarity reasons) - mapping record properties names to table columns.

Does

{
    id = Guid.NewGuid()
    first_name = "Works"
    last_name = "Great"
    date_of_birth = DateTime.Today
    position = 1
}

work for you?

[mnebes]

Hi Roman, thanks for the quick reply!

Understood, yes this works, so we can get around this issue, no problem. This just looks kinda funny as a F# record without PascalCase, that's why I was wondering if it could be a feature, but I completely understand your hesitation.

[Dzoukr]

I agree it's funny. BUT... On the other hand, it will show that the record's existence is there only for DB reasons (as row interpretation) and should be mapped into the domain as soon as it leaves DB context. I am still not sure if this is bug in Dapper.FSharp library or essential feature 😄

[mnebes]

I also thought it could be a nice indicator that such a record should never leave the context of data access. Anyways, if you decide against such a feature just close this issue, as I said, I can easily work around this. Of course if you decide for it I'd be happy to help with the implementation!

[Dzoukr]

Thanks for the offer, Michal, but I decided not to complicate the library. Custom mapping over column names is a rabbit hole in the long-term and I'll keep trying to avoid it as long as possible.