TangSiyang2001 opened a new pull request, #19142:
URL: https://github.com/apache/doris/pull/19142

   # Proposed changes
   
   Issue Number: close #18476
   
   ## Problem summary
   
   Try to do:
   1. make InsertStmt as facade layer
   2. implement LoadStmt related content in proxies' way.
   3. collect public properties for all loads
   
   Make InsertStmt as a facade layer, and all corresponding load behavior will 
be proxy to the related stmt proxy, which implements the real analyze behavior 
and holds the implemented data structures.
   
   A key principle is that, all load behavior, including the native insert, can 
be described well as data_desc, which describe the loading data, and resource 
desc, which clarify the load source. (Here we omit properties and other public 
parts, just discuss about the distinctive content).
   
   There are only two purposes that we call insertStmt in code.
   1. analyze it and keep the result in it
   4. get the analyze results when we make exec plan.
   Therefore, we can try to store most of these info in data_desc and 
resource_desc according to its attribute, and use it like
   ```java
   MyInfo info = insertStmt.getDataDesc<MyDataDesc>().getinfo();
   ```
   rather than
   ```java
   MyInfo info = insertStmt.getInfo();
   ```
   We can easily to hide diversity of different load and make some unified 
interfaces in the facade layer.
   
   The long-term goal is to unify the data desc and resouce desc, currently in 
early term of refactor, just keep the different desc and use a marked interface 
to unify them in facade layer (or use generics for InsertStmt class if no heavy 
job in need).
   
   ## Checklist(Required)
   
   * [ ] Does it affect the original behavior
   * [ ] Has unit tests been added
   * [ ] Has document been added or modified
   * [ ] Does it need to update dependencies
   * [x] Is this PR support rollback (If NO, please explain WHY)
   
   ## Further comments
   
   If this is a relatively large or complex change, kick off the discussion at 
[[email protected]](mailto:[email protected]) by explaining why you 
chose the solution you did and what alternatives you considered, etc...
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to