Wonderful Relation Queries:
A query in Wonderful relations is close to an sql query – with some specialitys. Queries are the Keypart. As higher the enties a linked, in a normal developement context the coding and creating queries is very complex. We often see a workload exponential to the number of links.
In the Wonderful Relations concept we use this layer to query data from our tables and present it as tables.
How does it differ from a SQL Query?
In many models you have also subtables like… so different queries are need… When we need more than a Table it is very hard to do this with one database query.
In our model you can create a query for projects and queries for manager and develpoers.
In the project query you can add the person queries as subqueries. (Reusability of queries).
We can join querys with queries based on our link functionaliy. Querys can have subqueries for viewing subtables in the views.
– What is as Cached Query?
Cached querys are build only one time and stored in the query table
– What is as Base Query?
For reusing queries and joins there exists a big rewriting problem. we solved this that in every step we use a rewriting of all columns init “vxxx” fields.
Sometimes we want to have a query that gives us only a basic table with the original tablenames. so when this option is used, we do not rewrite anything.
- Cache Query
- Base Query
- Subtable Search
- Database Table
Special cases: DUAL, VIEWS…
To have a clear “view” we have to define what entity does a query return. This information is used for joins, etc…
This identifier is used to access query from php code.
QueryExecutor::execute_query_by_identifier( 'identifier', $parameter ); QueryExecutor::execute_query_by_identifier_get_row( 'identifier', $parameter );
For deeper information, how to use Worderful Relations queries in your plugins, see the QueryBuilder / Executer documentation.
If you enable this option, the query will be build only once, and stored in the database. If a query is loaded, since we use a singlton pattern, it is also stored in ram, so it is only loaded once from database in a instance.
The default in wonderful relation is to rename the field in every select like (v1,v2,v3,…). This allows us to join queries without thinking about uniquity of field names. In some cases, expecially when we use queries in code like in the example above, we want to have a “base” result, so column names should not change. So the most underlying queries are “base” queries.
When enabled, subtables will be included in search. This forces the database to do all joins and perform search on the full result. If any subtable entry matches, the entry and all subtable entries will be shown.