Name Resolver and Mapping Resolver in OQL

Two conceptual objects in OQL

Case 1: replace attributes with column names and objects with table names. Select UserId, UserCode, UserName from User

Result: Select Usr_Id, Usr_Code, Usr_Name from Sys_User

Case 2:
The User object specifies an alias, so a. UserId needs to determine the attributes based on the alias. UserId comes from the User object, and then replaces UserId with the column name.
There are subqueries, so t. createBy needs to search for the object from which the CreateBy attribute comes from in the subquery. In this case, you can find the object from Org. Therefore, you need to replace it with the self-segment name mapped to the CreateBy attribute on the Org object. Select .*
From User
Inner join (
Select distinct CreateBy from Org where OrgId =?
) T on t. CreateBy = a. UserId

Result: Select .*
From Sys_User
Inner join (
Select distinct Create_By from Sys_Org where Org_Id =?
) T on t. Create_By = a. Usr_Id

Case 3: the more complicated the situation is.
The only difference between this case and case 2 is that the select attribute in the subquery specifies an alias and the attribute name is the same. Therefore, t. CreateBy should not be replaced. Select .*
From User
Inner join (
Select distinct CreateBy as CreateBy from Org where OrgId =?
) T on t. CreateBy = a. UserId

Result: Select .*
From Sys_User
Inner join (
Select distinct Create_By as CreateBy from Sys_Org where Org_Id =?
) T onT. CreateBy= A. Usr_Id

Case 4: more complex cases. In a hypothetical statement, the interface of the anemia model often has similar requirements. The general business significance may be: a parent-child relationship with a table. Perform a fuzzy query by parent node name to display information about all child nodes, including the parent node name and the user who created the child node.
Name Resolver is difficult to make decisions for ing replacement.
After the decision-making process enters the subquery, two objects are encountered. For t. ParentName, the select list of subqueries specifies the alias, so it should not be replaced. For t. CreateBy and t. OrgCode, make a guess in the subquery. First, the two fields specified in the select list of the subquery cannot be found. Therefore, we have to check the locations where the column names are not explicitly specified. Only one c. *, so confirm t. createBy, t. orgCode attributes must come from c. * Find the Org object in Org as c according to the alias c. These two attributes need to be replaced with the self-segment name. Select t. *, a. UserName as CreateUser
From User
Inner join (
Select c. *, p. OrgName as ParentName from Org p, Org as c
Where c. ParentId = p. OrgId
) T on t. CreateBy = a. UserId
Where t. ParentName like? Parent
Order by t. OrgCode

Result: Select t. *, a. Usr_Name as CreateUser
From Sys_User
Inner join (
Select c. *, p. Org_Name as ParentName from Sys_Org p, Sys_Org as c
Where c. Parent_ID = p. Org_Id
) T onT. Create_By= A. Usr_Id
WhereT. ParentNameLike? Parent
OrderT. Org_Code

It is impossible to determine the relationship between object-alias and Attribute-alias completely from the statement. For example, in case 4 above, if two * s are found in the select list of the subquery *, how to make a decision?
Method 1: Make syntax restrictions so that the OQL statement can clearly determine the relationship.
Method 2: Search the metadata of O-R ing for further analysis and confirmation. In this aspect, it is required to have an overall loading process for all the ing metadata at the application startup (similar to the compilation process when Hibernate's SessionFactory was created ), on the other hand, the same name attribute of different objects and objects with the same name in different namespaces still cannot be avoided.
Method 3: Leave the space for flexible use by the Client. If this problem exists, the selection list must be specified explicitly.

Search from OQL statements and try to determine the relationship between objects, attributes, and aliases. This role is assigned to Name Resolver.
Maintain the ing information and determine which tables and segments the objects and attributes should be mapped to and how to map them. This responsibility is borne by Mapping Resolver/Manager.

Name Resolver can tell Mapping Resolver to perform precise ing when making accurate judgments. When Name Resolver cannot make a decision, it also submits the baton to Mapping Resolver. At this time, Mapping Resolver can adopt a fuzzy search. For example, in an ObjectQuery range, search all the Type ing information of the ObjectQuery from Attach (the user is required to display the call ObjectQuery. attach (Type type, string name) method to avoid the overall loading of all metadata); or load all ing metadata, fuzzy search from the entire ing metadata (the possibility of misjudgment is relatively high when there is a conflict of names, so that the user can see that Attach will narrow down the scope and facilitate the resolution of the conflict ).

ObjectQuery can return a collection of object objects, or an IList <object> or able. Nhibist selecting to return IList <object> saves one thing, because if the DataTable is returned, each returned field must have a name corresponding, not just index access. As shown above, when the query is executed, the name of the genus has been replaced with the field name. If the DataTable is returned in this way, this function is awkward. First, the query statement writes the object and attribute names, while the returned DataTable is the database field name. When this DataTable is used, do I still use the database field name for access?
Therefore, if you choose to return DataTable, the best way is to replace the object and attribute in the statement with the table name and field name of the database so that you can execute this SQL query. However, the select list can also be returned by alias or attribute name, especially for select. *, B. * In this case, Name Resolver needs to find out the specific objects of a and B, and Mapping Resolver can find out the attribute names of these objects. The situation is very complicated considering various situations such as subqueries.
Therefore, the IList <object> is returned.

The more complex case is the association between entities, which is reflected in OQL and also requires collaboration between Name Resolver and Mapping Resolver.
Result:
Name Resolver and Mapping Resolver have a lot of collaboration and strong association relationships in terms of interaction mechanisms. However, they have completely different professional knowledge and work in different fields, therefore, good separation is required.