Modify $filter so that sub-objects can be filtered when queried.

[ccoddington]

No description provided.

[pofider]

Thanks. It seems to me this should be done in the odata server itself rather than in the adapter. Don't you think?

https://github.com/pofider/node-simple-odata-server

[ccoddington]

That makes sense as long as it isn't adapter specific. The beauty of this library is that we can use any data-source as our data-store assuming we are willing to write the adapter. In the case of relational databases, I think this dot-notation would work with minimal tweaking, however, if we were to use an XML data-source, we would likely make use of xPath for queries and we would want to keep the slash separator.

[ccoddington]

In order to support $expand operations the data model must be modified as follows:

1. The entitySet entry must have a a new 'joins' property that contains an array of Mongo $limit objects. As an example:

user: {
entityType: 'namespace.User',
joins: {
address: {
from: 'address',
localField: '_id',
foreignField: 'userId',
as: 'addresses',
},
shift: {
from: 'shift',
localField: '_id',
foreignField: 'userId',
as: 'shifts',
},
},
},

2. The entity model must be modified to have a placeholder field otherwise the pruning process will remove the joined entities. As an example:

User: {
_id: { type: 'Edm.String', key: true },
email: { type: 'Edm.String' },
firstname: { type: 'Edm.String' },
lastname: { type: 'Edm.String' },
phone: { type: 'Edm.String' },
languageCode: { type: 'Edm.String' },
isDeleted: { type: 'Edm.Boolean' },
dateCreated: { type: 'Edm.DateTime' },
dateUpdated: { type: 'Edm.DateTime' },
addresses: { type: 'Collection(namespace.Address)' },
shifts: { type: 'Collection(namespace.Shift)' },
},

In the previous example, 'addresses' and 'shifts' are placeholder fields. In the event that a join does not take place, those fields will not be returned to the client.

3. The placeholder fields require an associated entry in the 'complexTypes' object.

[pofider]

Hm. The entitySet "joins" property is something that comes from the odata standard or it is something custom you came up with? Isn't this covered in odata navigation properties?

I think this gets quite complex if it gets implemented correctly.
The simple-odata-server should generate correct $metadata model and there are other aspects to consider.