Linked Records Sub Filtering

[shogunpurple]

Depends on: #575

A user should be able to filter based on the value of linked fields in a record.

For example, a Student may take many Classes.

When creating a view for Student, we should be able to filter the view down based on the linked records for that student. For example:

Give me the students who attend classes beginning with Z

This means that the couchDB views need to be aware of the linked records for each record.

[mike12345567]

This issue will need to be discussed as I am not sure this is something that can easily be handled with a view. A view is only capable of considering each document itself, it cannot access external documents as part of the map function, there is also no way to emit an ID to include, the include_docs parameter only includes the linking documents themselves, not the documents that have been linked to.

To handle this I believe the only way it can be done is to define our own filtering syntax for linked filtering which we attach to the view as custom parameters, after the view has executed we then have to in-memory filter it after retrieving all of the linked documents. The problem with this is that its a recursive problem and our filtering syntax would need to have essentially the capabilities of an SQL WHERE on a JOIN statement.

Would love to hear your thoughts on this, I think the only way this could be handled purely by a view in Couch would be for linked records to simply be nested inside their parent records, this would however mean many to many relationships are impossible without crazy duplication.

[aptkingston]

If this is just a requirement for the backend UI (like just to allow a user to query their DB from the builder) then it could be implemented as just an in memory filter in the browser. This wouldn't be saved with the view and so couldn't be used as a datasource for a frontend component, but would at least allow a user to perform that sort of lookup. I'm not sure if that's even useful by itself though, so it just needs to be decided what's the best way to go on this.

[shogunpurple]

After the most recent developments around views and their sluggish performance without very much scale, I think we might want to steer well clear of this one, at least for now. It's very difficult to architect and even harder to get to perform. Complicated calculations and nested calculations are essentially out of the question until we figure out how to make normal ones faster. Since we don't really know much about how this would be implemented, I'm going to convert this issue into a github discussion. It's not ready to be worked on yet