Unpolish proposal for Tabular Joins

[ramonbmt]

Proposal for Tabular Joins using the mongo aggregator pipeline in both publish with the capability of performing search on the joined collection.

Usage: this.table = new Tabular.Table({ name: 'Test', collection: invoiceCollection, columns: [ {data: "invoiceNumber", title: "Invoice Number"}, {data: "client.profile.name", title:"Cliente"}, . . . ], responsive: true, autoWidth: false, joins:[ {from:"users",localField:"createdBy",foreignField:"_id",as:"client",unwind: true (optional)} ] });

[VansonLeung]

This will solve my issue for over a year, let me test it

[aldeed]

@ramonbmt @VansonLeung Has anyone been using this in production with success? I'd like to solve this issue for people, but this package is already quite complex so I'm wondering if you can think of a way to add in some hooks that would allow joins support to be in a separate add-on package. I'll give it some thought, too.

[ramonbmt]

Hi, i am using an extended version of this fix in multiple systems in production. And actually i ran into a problem recently that could be solved with a hook like that. But dont know how it could be the best way to achieve it. As i can see, you have 2 publish, one for the keys and the other for the full data for those keys. wouldn't it be better to just have 1? Also, right now you have a way to subscribe to a custom publish, but only works for the second publish, the one that sends the full data for the keys. If you just have 1 publish, you could control all the de data that the table receives with just 1 custom subscribe. The other problem that i have, that could benefit from this, is that i want to create a table with the result of a group.

[VansonLeung]

My production examples: https://www.youtube.com/watch?v=QXbcSZBkoxU

I overrode the 2 tabular publish methods with my own logic, powered by a Reactive Aggregate plugin.

@ramonbmt 's solution is better & more systematic (can configure Joins) compared to my code logic (automatically find all Joins for specific schema types), but we are adopting very similar methods

The only reason I want it to be aggregated is: everytime when I could not explain to my clients we could not do Searching over the relational fields, it triggers me the urge to fix this

[aldeed]

@ramonbmt The reason for having 2 pubs was so that all of the complex logic could be in the first one, and that way people updating the second one to join related data only have to look at a list of IDs rather than rewriting all of the query logic. But yes, we could make both of them overridable, and it might be possible to have an option where there is only 1 pub.