First off, I've followed the project for a while and have been very impressed with what you all have built.
So - I have a technical requirement that I'm concerned is not quite in Teiid's wheelhouse, (or might be completely outside of what Teiid's designed for) but I'm wondering if their is a way it could help us.
The explanation is a bit long, so bear with me.
We are a hosted application that provides functionality for partners in international trade transactions. Single big database for everyone with view rights granted dynamically depending on who's part of any "transaction". This is acomplished with a "Viewer" table like so:
Aka - To find all shipments that partyID 123 can see:
SELECT * FROM Shipment, Viewer WHERE Shipment.VIEWERID = Viewer.VIEWERID AND Viewer.PARTYID = 123;
Additionally, some fields in these transactions are represented as columns on tables, and some are "custom" - aka specific to a customer, and as such are represented using generic tables (FieldID, TransactionID, FieldName, FieldVal, FieldDataType).
The Problem: Provide an ad-hoc reporting enviornment for those customers wanting it. Traditional business intel/reporting server tools don't seem to fulfill what we want.
- Really awesome would be a jdbc connection (or web service/api/etc) that customers could use to run simple reports or that they could connect a fat client reporting design tool at. (Reports could either be run remotely, or even better, designed and then sent to us to be run).
- This JDBC connection would differ from the actual physical db in at least two important ways.
- All data tables like the "Shipment Table" expressed above would be views with the Viewer auto-magically connected.
- The generic field tables would be "pivoted" out to appear to the customer like normal tables.
I'm aware this is pretty much what Salesforce's web services do, and I'm jealous.
Some constraints that make me worry that I'd need to abuse to Teiid to get it to help:
- Number of unique 'schemas' - probably one per customer (4-5k). If I used a VDB per customer, would Teiid even be okay deploying that many? And then creating that many by hand.. Hmm, sounds rough.. Dynamic VDB's seem cool, but View layers sound like what we would need, and they don't seem to be supported dynamically.
Brainstorming I've done on how I might get my way anyway:
- If VDB's are mostly the same with just different PartyID's hardcoded into the Views, maybe I could programatically post process an xmi from the designer. (I'm aware this is frowned upon or could be impossible)?
- Looking at custom resource adapaters, it occurs to me that some of this customization could be pushed back into that part of the stack. We have a pretty roboust SQL parser built off antlr. Maybe less VDB's and inject this join/constraint at statement level?
- A custom resource adapater could also present it's own version of metadata. Perhaps this could allow the use of dynamic vdb's while still allowing some control. Am I going to just end up re-inventing Teiid (poorly) if I do this?
- Original idea was to point Teiid at the database and have it handle security/view transformation. Maybe we create custom adapater to push data through our app server. Teiid becomes our highly available JDBC server?
Any general throughts on this would be very much appreciated. I'm aware this is a *big* problem, but if anyone could let me know if I'm thinking even remotely reasonable things.. Do I need to go back to the drawing board? Am I missing some simple solution??
Well - thank you all for your time and any thoughts.