[ 
https://issues.apache.org/jira/browse/HIVE-24217?focusedWorklogId=502050&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-502050
 ]

ASF GitHub Bot logged work on HIVE-24217:
-----------------------------------------

                Author: ASF GitHub Bot
            Created on: 19/Oct/20 07:40
            Start Date: 19/Oct/20 07:40
    Worklog Time Spent: 10m 
      Work Description: zeroflag commented on a change in pull request #1542:
URL: https://github.com/apache/hive/pull/1542#discussion_r507534867



##########
File path: standalone-metastore/metastore-server/src/main/resources/package.jdo
##########
@@ -1549,6 +1549,83 @@
         <column name="RM_DUMP_EXECUTION_ID"/>
       </index>
     </class>
+
+    <class name="MStoredProc" table="STORED_PROCS" identity-type="datastore" 
detachable="true">
+      <datastore-identity>
+        <column name="SP_ID"/>
+      </datastore-identity>
+      <field name="createTime">
+        <column name="CREATE_TIME" jdbc-type="integer" allows-null="false"/>
+      </field>
+      <field name="lastAccessTime">
+        <column name="LAST_ACCESS_TIME" jdbc-type="integer" 
allows-null="false"/>
+      </field>
+      <field name="database">
+        <column name="DB_ID" allows-null="false"/>
+      </field>
+      <field name="name">
+        <column name="NAME" length="256" jdbc-type="VARCHAR" 
allows-null="false"/>
+      </field>
+      <field name="owner">
+        <column name="OWNER_NAME" length="128" jdbc-type="VARCHAR" 
allows-null="false"/>
+      </field>
+      <field name="source">
+        <column name="SOURCE" jdbc-type="MEDIUMTEXT" allows-null="false"/>
+      </field>
+      <field name="language">
+        <column name="LANG" jdbc-type="varchar" length="128" 
allows-null="false"/>
+      </field>
+      <field name="returnType">
+        <column name="RET_TYPE" jdbc-type="varchar" length="128" 
allows-null="true"/>
+      </field>
+      <field name="parameters" table="SP_POS_ARGS" >
+        <collection element-type="MPosParam"/>
+        <join>
+            <column name="SP_ID"/>
+        </join>
+        <element>
+          <embedded>
+            <field name="name">
+              <column name="NAME" jdbc-type="varchar" length="256" 
allows-null="false"/>
+            </field>
+            <field name="type">
+              <column name="TYPE" jdbc-type="varchar" length="128" 
allows-null="false"/>
+            </field>
+            <field name="length">
+              <column name="length" jdbc-type="integer" allows-null="true"/>
+            </field>
+            <field name="scale">
+              <column name="scale" jdbc-type="integer" allows-null="true"/>
+            </field>
+            <field name="isOut">
+              <column name="OUT" allows-null="false"/>
+            </field>
+          </embedded>
+        </element>
+      </field>

Review comment:
       > That was a suggestion to provide a way to store a human readable..
   
   I understand it is only for showing the user, but it it feels like an 
afterthought, I don't really like it. It adds redundancy and it only has a 
single use. The structured information can be used to generate this output, (or 
in fact other outputs, like showing the parameters in a table) or to supply 
meta programming information to various tools, like code completion tools or 
method finders.
   
   For example, search for the return type:
   
   ```
   int i = fn.. // find every function that starts with "fn" and returns an int
   ```
   
   Although this is a search for the return type not on the parameter but it's 
the same problem since the return type is also part of the signature.
   
   I we had higher order functions (in fact JavaScript has and that might be 
the 2nd supported language) then:
   
   ```
   filter(fn.., listOfString); // find every function that starts with "fn" and 
takes a single string parameter
   ```
   Method finder:
   
   This might look like a bit scifi, there are only 2 programming environments 
I'm aware of, which know how to do this.
   
   ```
   MethodFinder.methodFor('somefile.txt', 'txt'); // find which method returns 
the extension part of filename, by an by example,
   ```
   
   It will return:
   ```
   "FilenameUtils.getExtension()"
   ```
   
   These things might sound unimportant but I think language design and tool 
development shouldn't be separated. Tool support should be considered from day 
1 when creating a language.
   
   
   > If at some point in time the "parsing" will prove to be a bottle neck
   
   I'm was not talking about parsing as a bottleneck (though it could be) but 
interpreting the AST (method body) as a bottleneck. I can't think of any 
imperative language that can be taken seriously that works that way. Perhaps 
shell scripts, or early versions of Ruby which was notoriously slow so later 
they changed it.
   
   > I think we should clarify/separate 2 things
   
   If we only allow defining procedures in terms of the "host language", then 
this is true indeed. My assumption was that we might want to accept procedure 
definitions in terms of the "foreign language". For example function(x,y) {}. 
But ok, let's say this is not allowed. Then you're right, using the alternative 
format seems to be viable if we don't count the other issues.
   
   If we go to that route, what would you do with the other columns which are 
also part of the signature, like "LANG", "RET_TYPE", "NAME" ?
   
   ```
   CREATE FUNCTION func1(a int) RETURNS int LANGUAGE XX BEGIN ... END;
   ```
   
   > I don't know what feature you are refering 
   
   It's probably that one. I think that illustrates nicely why parsing is not 
always a prerequisite of calling a procedure. 
   




----------------------------------------------------------------
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.

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Issue Time Tracking
-------------------

    Worklog Id:     (was: 502050)
    Time Spent: 2h 20m  (was: 2h 10m)

> HMS storage backend for HPL/SQL stored procedures
> -------------------------------------------------
>
>                 Key: HIVE-24217
>                 URL: https://issues.apache.org/jira/browse/HIVE-24217
>             Project: Hive
>          Issue Type: Bug
>          Components: Hive, hpl/sql, Metastore
>            Reporter: Attila Magyar
>            Assignee: Attila Magyar
>            Priority: Major
>              Labels: pull-request-available
>         Attachments: HPL_SQL storedproc HMS storage.pdf
>
>          Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> HPL/SQL procedures are currently stored in text files. The goal of this Jira 
> is to implement a Metastore backend for storing and loading these procedures. 
> This is an incremental step towards having fully capable stored procedures in 
> Hive.
>  
> See the attached design for more information.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Reply via email to