[
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:
[email protected]
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)
