[
https://issues.apache.org/jira/browse/HIVE-24217?focusedWorklogId=502091&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-502091
]
ASF GitHub Bot logged work on HIVE-24217:
-----------------------------------------
Author: ASF GitHub Bot
Created on: 19/Oct/20 10:19
Start Date: 19/Oct/20 10:19
Worklog Time Spent: 10m
Work Description: kgyrtkirk commented on a change in pull request #1542:
URL: https://github.com/apache/hive/pull/1542#discussion_r507634498
##########
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:
> I understand it is only for showing the user, but it it feels like an
afterthought, I don't really like it.
Okay; then we don't need to add and store it - we could also use a simple
UDF to get the signature if we want that.
About `search for the return type` I think we should come up with a
"working solution first" and go after these things when we need it (maybe
never?)
I think that `MethodFinder.methodFor` will need a lot more than just a
signature...so it's a little bit too much
> 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.
We may leave this thing out completely right now - because we don't need it
right now.
I think instead of adding something which may not perfectly align with our
future needs ; leaving something out will not lock us in at all.
> but interpreting the AST (method body) as a bottleneck.
that's the problem of the language implementation itself - I think in case
the language function is defined in some kind of "text" then we should store it
as "text" - to have a less convoluted contract with the embedded language.
> 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".
yes; we should only store those procedures/functions which are usable from
the HiveQL - don't we?
> `CREATE FUNCTION func1(a int) RETURNS int LANGUAGE XX BEGIN ... END;`
I think we should simply store the whole definition from `CREATE` to the
closing `;`.
Storing anything less could become unparsable.
> > 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.
There might be some misunderstanding here by "parsing" - I mean to process
it with the host sql language.
If the client language has performance issues doing parsing/etc is then that
issue belong to the language itself.
In case the language is an on-the fly interpreted language which also
happens to have a compiled version ; then that other version could either be
registered as a separate language (and refer to a binary somehow) or the
language could add some caching/etc to avoid unneccessary parsing overhead.
Couldn't we do something like this for hplsql?
In any case: I think that extending the basic implementation with a "generic
blob storage" option to provide additional services for the stored procedures
(which could potentially be used to speed up sql function execution) should be
a separate feature - and as such; should be discussed(and implemented)
separetly.
(Honestly I think there would be marginal benefits implementing this - and
could be dodged by the client language implementation with a few caches/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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
Issue Time Tracking
-------------------
Worklog Id: (was: 502091)
Time Spent: 2.5h (was: 2h 20m)
> 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: 2.5h
> 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)
