Spike related to foreign key handling in CQLPGJson
This will be a location for notes related to - CQLPG-95Getting issue details... STATUS
Problem statement: CQLPGJson does not understand views.
Options:
- use the existing schema.json information that is responsible for setting up views and generate queries that utilize those views directly in CQLPG. This might require more complex traverse of the table and view structure by CQLPG, based on what fields are included in the query (e.g when the query includes fields that are not contained within the base table specified when invoking CQLPG, CQLPG would have to find the required view and use that instead)
- Make the parser aware of views. (possibly by incorporating the dbtables object as a view holder and flagging it as such)
- Whenever some properties about the Table(now possibly a view) are needed, have to check whether it is a view or not.
- If it is a view we need to examine the tables the view is made up of and grab the fulltext/etc that is needed to optimize
- Base decisions made after that on information found about resulting tables and not just the view(which wont have any indexes)
- redesign how the FK and relationship information is stored in schema.json and based on the information generate nested SQL queries directly in CQLPG not using views. This on the other hand will result in a more complex SQL query (nested)
- Does this even need additional information in the schema.json? Maybe it would speed the process up if there was. Would have to analyze the view tables columns to find the information…
- Add logic to detect when fields are in different tables, then join based on known information
- Create a join or sub query(or just re use the sub query logic already in place) to retrieve the info
- Add notation in CQL for hinting at a view use. This will require changes to existing cql
- I am dismissing this option due to perceived need to change many cql queries already implemented.