POC of Mql.Field (could be used by EF Core Provider to support shadow properties).

[rstam]

No description provided.

[rstam]

We need to know the container, even if it is only the root.

X is like a shadow property. It exists in the document in the database but not in the class C.

[JamesKovacs]

I like the overall technique. If we are going to productionize it, we probably would want to make the serializer optional, which poses some challenges. root => Mql.Field<int>(root, "X") + 1 feels more natural, but C# doesn't allow partial generic type inferencing.

I can see where specifying the serializer makes sense for advanced use cases, but in common cases such as strings, integers, bools, etc., it will be more useable to specify the field type.

[rstam]

The serializer is important because it defines how the field is represented in the database.

If it is not provided, where would we get it from? The only reasonable place would be the BsonSerializerRegistry, but there is no guarantee that the serializer registered there is the correct one for this particular hidden field in this particular POCO.

[damieng]

Tested and working well with the EF Shadow Properties implementation and also for select projection rewriting.

[damieng]

Two open questions here:

1. Should the string "fieldName" second parameter of Mql.Field be elementName or even elementPath?
2. When using Mql.Field I'm seeing:

{ "$match": { 
   "$and": [
      { "$expr" : { "$eq" : ["$planetId", { "$oid" : "621ff30d2a3e781873fcb663" }] } },
      { "$expr" : { "$eq" : ["$label", "VI"] } }
   ] 
},
{ "$limit" : 1 }

But when executing against the same properties as CLR properties I get a quite different query:

  { "$match" :
  	{ "_id.planetId" : { "$oid" : "621ff30d2a3e781873fcb663" },
  	{ "_id.label" : "VI" } 
  }, 
  { "$limit" : 1 }

Why are the ones from MqlFied using $expr and why do they get wrapped in an additional $and ?

[rstam]

Why are the ones from MqlFied using $expr and why do they get wrapped in an additional $and ?

Because initially I only implemented Mql.Field for aggregation expressions and not for filters.

The $and is required because implicit and can't be used when there are two $expr in the same document (that would be duplicate field names).

[rstam]

Should the string "fieldName" second parameter of Mql.Field be elementName or even elementPath?

It's a bit arbitrary when we use "field" and when we use "element".

I don't think the server team ever uses the term "element". To them it's always a "field".

[rstam]

or even elementPath?

Not sure about paths... I was envisioning that Mql.Field would descend EXACTLY ONE level. If there are more levels you can compose multiple Mql.Field uses to descend to the nested field.

[rstam]

or even elementPath?

Looking at this in more detail I believe that Mql.Field can only descend one level.

Mql.Field translates to the MQL $getField operator which only descends one level at a time.

The server expects you to nest calls to $getField to descend multiple levels.

[rstam]

I've pushed a new commit adding support for Mql.Field in filters.

[damieng]

POC working great here now as the backing for EF-42 (shadow properties).