Analysis on the inconsistency of the structure of type erase \union table

The type erasure mentioned in this article is related to overloading in Java. Let's take a look at the overloaded definition: overloading is the manifestation of Java polymorphism, and is a mechanism for processing different data with a unified approach. Overloading of Java methods, that is, methods have the same name, but the parameter list (type or number) is different.

Here are two methods I wrote to add a list of users or lists of different types of users to a data structure that contains recipients, subjects, and message bodies. As follows:

private void Addemailrecipients (Flowruntime startflowruntime,list<string> userids, Processcontext context, List <Task> taskList) private void Addemailrecipients (Flowruntime startflowruntime, list<set<string>> Usersetlist, Processcontext context, list<task> taskList)

Without careful observation, the parameter list is similar, the only difference is the second parameter, Method 1 is list<string>, Method 2 is List<set<string>>, and I think this parameter list is different and can be considered overloaded.

However, at the time of saving, the compiler reported the following error:

Method addemailrecipients (Flowruntime, List<string>, Processcontext, list<task>) has the same erasure Addemailrecipients (Flowruntime, List<e>, Processcontext, list<e>) as another

Method in Type Processactivityservice

Search for keywords such as the same erasure, which is called "Java Syntax Sugar flavors: generics and type Erasure", from The deep understanding of Java Virtual machines: JVM advanced features and best practices .

　　This paper mainly discusses the implementation of generics in Java syntax. Here is a brief summary of what I read from the previous article:

Generics are a mechanism for more extensive application of parameter types as parameters, and in C + +, C # There are similar mechanisms for templates and generics. Generics in Java are different from the generic implementation mechanisms of other languages, and are a pseudo-generic based on erasure. For example, list<string> and list<integer> are different during code writing, but are converted to native types in compiled bytecode files. We know that the implementation of a generic type before JDK1.5 appears is implemented by continuing and type-strong implementations, and the generics in the bytecode file appear to have returned to the JDK1.5 before. About why Java uses this mechanism to achieve generics, different people have different solutions, such as efficiency. But for example, the two methods in our code above, such as we change one of the return values to other types, compilation is possible. The article also explains the so-called signature signatures (source code signatures, which contain only parameter types, numbers, etc.) and method descriptions (byte code signatures, including parameter lists and return values, native types, etc.). Overloading is based on the special signature of the bytecode, and the return value does not participate in the special signature, but the original paper type Erase error method plus different return values can be compiled, this is because as long as two different methods described by the method can exist in the same bytecode file, so through the compilation. In addition, the article also on why the type is erased after compilation, we can get its original type through the mechanism of reflection and so on. This is because the type erases the code-level bytecode file, but the special signature contains metadata special signatures that retain the original type.

2.2.1) ERROR 1222 (21000): The used SELECT statements has a different number of columns:

this is because the table structure of the records generated by the two SQL statements using Union is inconsistent. You must be a fully consistent set of records before you can use Union. The above is the result of a different field of two tables. Here's the SQL we're using. This is a statement that queries all code for work. The first half is to query all the JBPM in OA, while the bottom half is to query all the pending work from another system. Because the new requirements need to be in the OA jbpm to add the principal, the transfer of people and other attributes, and other systems to do work does not have similar concepts. An inconsistency in the table structure between the two union statements resulted in the above error.

Workaround:

' As newfiled

<select id= "Querymytodotask"  resultmap= "Executionresultmap"   parametertype= " Com.fx.oa.module.bpm.workflow.api.shared.domain.ProcessExecutionEntity ">selectpexec.id,ptask.taskid, Ptask.activityname,ptask.substituteusercode,pexec.processdefineid,pdefine.name,pexec.processinstanceid, pexec.tablename,pexec.formdefineid,pexec.pkvalue,pexec.urgencydegree,suser.username as  ' Createusercode ', Pexec.createtime,pexec.active,pexec.status,pexec.id as todourl,pexec.id as  relateid,pexec.id as domainfromt_bpm_process_task ptaskleft outer join t_ Bpm_process_execution pexec on ptask.processexecutionid = pexec.idleft outer  JOIN t_bpm_process_define pdefine ON pexec.processDefineId =  pdefine.idleft outer join t_sys_user suser on pexec.createusercode =  Suser.usercode and suser.accesscontrol= ' Y ' Where ptask.taskid in  (Select distincttaskimpl.dbid_fromjbpm4_task taskimplleft outer join  jbpm4_participation participat on taskimpl.dbid_ = participat.task_ wheretaskimpl.assignee_ = #{createusercode}or  (taskimpl.assignee_ is nulland  participat.type_ =  ' candidate ' And participat.userid_ = #{createusercode})) AND  Ptask. Status = 0and pexec. status in  (1, 6,8) and pexec.active =  ' Y ' <!--<if test= "CreateUserCode  != null and createusercode != ' ">             and ptask.createusercode = #{createusercode}</if>  -- ><if test= "createusername != null and createusername !=" >             AND suser.userName LIKE  '% '  #{createusername}  '% '   </if><if test= "name != null and  name != ' ">AND pdefine.name LIKE  '% '  #{name}  '% '   </if><if  test= "startcreatetime != null and startcreatetime !=" >AND  pexec.createtime <! [cdata[>= #{startcreatetime} ]]>   </if><if test= "EndCreateTime  != null and endcreatetime != ' ">and pexec.createtime <! [Cdata[<= #{endcreatetime}]]>    </if>union select todo.p_ relate_id as id,todo.id as taskid,todo.p_activity_name as activityname , Todo.p_relate_id as processdefineid, '  as substituteusercode,todo.p_task_name as  name ,todo.p_relate_id as processinstanceid,todo.p_relate_id as tablename, Todo.p_relate_id as formdefineid,todo.p_relate_id as pkvalue,todo.p_urgency_degree as urgencydegree , todo.p_applicant_name as createusercode ,todo.p_applicant_time as createtime , ' Y '  as active,todo.p_urgency_degree as status ,todo.p_url as todourl  Todo.id as relateid ,todo.p_domain as domain from m_todo todowhere  1=1and todo.p_approval_id = #{createusercode}<if test= "createUserName !=  null and createusername != ' ">             AND todo.p_applicant_name LIKE  '% '  #{createUserName}  '% '    </if><if test= "name != null and name !=" ">AND todo.p_ task_name like  '% '  #{name}  '% '   </if><if test= ' startcreatetime  != null and staRtcreatetime != ' ">and todo.p_applicant_time <! [cdata[>= #{startcreatetime} ]]>   </if><if test= "EndCreateTime  != null and endcreatetime != ' ">and todo.p_applicant_time <! [Cdata[<= #{endcreatetime}]]>    </if>order bycreatetime desc </select>

This article is from the "South Lake Miner Technology Space" blog, please be sure to keep this source http://jncumter.blog.51cto.com/812546/1622182

Analysis on the inconsistency of the structure of type erase \union table