Saving record in RavenDb with F# adding extra Id column -

when save new f# record, i'm getting column called id@ in ravendb document, , shows when load or view object in code; it's being converted json through f# api.

here f# record type:

type campaign = { mutable id : string; name : string; description : string } 

i'm not doing exciting save it:

let save c : campaign =     use session = store.opensession()     session.store(c)     session.savechanges()     c 

saving new instance of record creates document id of campaigns/289. here full value of document in ravendb:

{     "id@": "campaigns/289",     "name": "recreating id bug",     "description": "hello stackoverflow!" } 

now, when used same database (and document) in c#, didn't id@ value. record looks when saved in c#:

{     "description": "hello stackoverflow!",     "name": "look worked fine", } 

(aside - "name" vs "name" means have 2 name columns in document. understand problem, @ least).

so question is: how rid of id@ property being created when save f# record in ravendb?

this combination of... well, can't quite call them "bugs", let's "non-straightforward features" in both f# compiler , ravendb.

the f# compiler generates public backing field id record field. field named id@ (a standard pattern f# backing fields), , it's public, because record field mutable. immutable record fields, backing fields internal. why needs generate public backing field mutable record fields, don't know.

now, ravendb, when generating schema, apparently looks @ both properties and fields. bit non-standard. usual practice consider properties. alas, raven picks public field named id@, , makes part of schema.

you can combat problem in 2 ways:

first, make id field immutable. i'm not sure whether work or ravendb. perhaps not, since id generated on insert.

second, declare campaign not f# record, true class:

type campaign( id: int, name: string, description: string ) =      member val id = id get, set     member val name = name     member val description = description 

this way, backing fields stay internal , no confusion arise. drawback have write every field twice: first constructor argument, class member.