Query
Queries are very similar to SQL script queries but are stored in LINQ format.
Actually they are transformed into SQL script representation by Entity Framework while executed.
Queries are needed for:
- combine several entities data at one row
- apply row level security
- exclude some rows based on your application business logic
(!) We recommend to always use Queries (not Entites) for user sensitive data that will help to manage row level security and will lead to more security robust applications. Non user sensitive data on the other side is better without Queries (for example, Country or Unit dictionaries).
Try to use as less Queries as possible while building your application this will lead to clean and easy to maintain design.
For example, instead of two Queries (Orders + filter IsActive=true; Orders + filter CurrentUser=true) use single Orders Query plus data source filters in Screen blocks.
Query properties
Section |
Name |
Description |
Basic |
Cached |
Used only in windows native client. If checked client will load results of the Query into memory on start. |
Basic |
Data Source |
Main data source. A list of Entities. |
Basic |
Name |
Machine name of a Query. This name would be used in source code. No whitespace or special characters are allowed. |
User Interface |
Description |
Useful to make notes about purpose of this Query. |
User Interface |
Display name |
Currently not used. |
User Interface |
Image |
Currently not used. Will be available later. |
Security |
IsPrivate |
If checked Query would be available only on server side. Any client or user will fail to assess this Query. |
Security |
Secured |
Specify if access to this Query should be based on permissions. If unchecked any registered user can have access to this Query. |
Security |
Create |
Select a permission or built in option for security logic. Built in options: <private> means that this option available only on server side (no controller methods or permission would be created). <auto> means permission would be auto created. You should run permission creation script on deployment to be able to see updated permissions. See Deployment chapter. <inherited> means that Entity Security.Create setting would be used. Should be set to some value except <private> to use in wizards. |
Security |
Read |
Select a permission or built in option for security logic. Built in options: <private> means that this option available only on server side (no controller methods or permission would be created). <auto> means permission would be auto created. You should run permission creation script on deployment to be able to see updated permissions. See Deployment chapter. <inherited> means that Entity Security.Read setting would be used. Should be set to some value except <private> to use in wizards. |
Security |
Update |
Select a permission or built in option for security logic. Built in options: <private> means that this option available only on server side (no controller methods or permission would be created). <auto> means permission would be auto created. You should run permission creation script on deployment to be able to see updated permissions. See Deployment chapter. <inherited> means that Entity Security.Update setting would be used. Should be set to some value except <private> to use in wizards. |
Security |
Delete |
Select a permission or built in option for security logic. Built in options: <private> means that this option available only on server side (no controller methods or permission would be created). <auto> means permission would be auto created. You should run permission creation script on deployment to be able to see updated permissions. See Deployment chapter. <inherited> means that Entity Security.Delete setting would be used. |
Query Filter
Filter is pretty much similar to WHERE clause in SQL script language, with the difference it could include local variables such as Permissions or Server Contexts.
(!) You should first add field to the list above to be able to use it in filter.
There are three types of fields to use in filter:
- Ordinary field - similar to WHERE clause in SQL script language.
- Field marked with @ symbol - these fields duplicate each available field and mean that it will be compared with Server Context variables.
- $PERMISSIONS field - can be used to check if current user has any of the selected permissions (for example, permission1 OR permission2 ...).
Second and third types in conjunction could be used to implement row level security.
(!) Notice that every other object that uses Query has its own additional filter. So there is no need to create a Query for each case, just create a common one and use additional filters in Screens or Wizards. But keep in mind security aspect - your common Query should not expose any data to a user if he should not see it.
See also
- Query Field in detail
- Row level security
- How to add Computed Field into Query?
- How to create right joins in your Query?
Created with the Personal Edition of HelpNDoc: Easily create EBooks