Cross-module DB access...
Jeremy: The data lives in other schemas, even if the views live in the FQM schema
Vince: The entire purpose of this module is to access/provide data from other modules. FQM does not directly access the other DB schemas, it effectively accesses other DB schemas via views.
Vince: From FQM's POV, it's just accessing it's own DB schema.
Vince: Ultimately, it comes down to the point that we NEED this capability in FOLIO to help us not only with lists app, but in several other areas as well.
Record deletion - design already in place
Bulk edit - mentioned earlier.
Data export - ability to filter record set being exported
Data import - performance improvements in matching BL
In-app reports - could be improved by using FQM
Vince: We DON'T want to open this up and allow module developers to do this all over the place. We want mod-fqm-manager to be THE place where this happens in FOLIO.
Jeremy: I think the creation/mgmt of views should not be FQMs responsibility. Other modules should "opt-in" to this somehow
Vince: the problem being solved here is that you need to join large datasets from different modules. Without FQM that means pulling down large responses from multiple modules, then finding the intersection/doing the join in BL. Using a DB join allows you to do this in the DB where it makes more sense
Maccabee: I support the RFC suggestion - It would be great to see a list of pros/cons, risks, etc.
Marc: What information do we need to make a decision today?
There's significant political will to get this into Poppy
There are 3 outcomes... allow, disallow, or run out of time and disallow by default.
Jeremy: The set of unknowns is unknown. I don't feel comfortable approving this module until we have time to go through the due diligence (RFCs, etc.)
Vince: There are two things at hand:
Jeremy: I feel uncomfortable treating a TCR as a way to make an architectural decision. The TCR fails the evaluation criteria.
Craig: There is some precedence for separating architectural concerns from a TCR – mod-settings for example.
Julian: mod-settings has solve permissions problems where this module has not yet solved.
Maccabee: We have in the past given a pass on certain criteria we thought is outdated, or unfair. In this case it's different.
Craig/Marc: Another option is to vote on conditional acceptance
Owen: that would allow this to go into Poppy, but we need to be cautious... This is underlying some other development. Conditional approval does not reduce the risk for that work.
Vince: We should also think about why we would be rejecting the TCR... could be:
We're being sticklers and this criteria isn't met.
We don't like how this played out - we would have liked it if the TC was involved earlier, etc.
We don't like this from an architectural perspective – <there was more here but I missed it>
Tod: From my perspective this seems like the direction we want to head (a central cross-domain broker for these types of things)
Vote for unconditional approval failed with 6 against
Vote for conditional approval passed with 5 for, 4 against.
Craig will draft a statement about why the TC approved this even with failed criteria. He will post to tc-internal and then update TCR if there aren't any objections to what is being said.