Graphback: MongoDB - forcing _id: ObjectID as key for providers?

[wtrocki]

Currently we remap to id: ID which is inefficient.
Logging as bug because setting custom primary key doesn't work - it actually overwrites valid data with the ObjectID data.

[wtrocki]

CC @ssd71 for discussion. (@craicoverflow for approval)
Do you think that will have any positive/negative impact on the DataSync features you have been building?

I'm looking to simplify our datasync providers that are overly complex now to handle all those cases and doing unneded mapping for returned data.

[ssd71]

Definitely, Simplifying API will definitely help, +100 on this as a developer but I haven't really thought about limitations and such but will definitely help me in DataSync

[wtrocki]

What limitations you mean. Generally forcing _id would be more aligned with how mongo works but we need scalar to avoid string to object id mapping.

See #1282

[ssd71]

Sorry for being unclear, I meant that I am not sure if there will be any limitations or not, but putting that aside I am 100% onboard with this

[wtrocki]

We are blocked by scalar support but apart from that this will simplify service layer nicely.

[craicoverflow]

One issue I see is that the API generation process in Graphback is generally detached from what data source you use - i.e it does not care.

How do we see making this work for both Postgres and MongoDB?

[wtrocki]

Price to pay when you have more than one datasource :D
_id will be documented for mongo. We can add validation?

[craicoverflow]

We can add validation?

Yep, it will have to happen very late in the data provider?

[wtrocki]

Sadly yes. As you have mentioned we are schema first and schema first solutions are usually working with single database. We are trying to be code first and schema first at the same time (by giving this services and some half-assed ability to work with functional services.