hadoop-pig-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Woody Anderson (JIRA)" <j...@apache.org>
Subject [jira] Commented: (PIG-928) UDFs in scripting languages
Date Mon, 15 Mar 2010 17:35:27 GMT

    [ https://issues.apache.org/jira/browse/PIG-928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845420#action_12845420
] 

Woody Anderson commented on PIG-928:
------------------------------------

@julien
have read over your code.

1. schema parsing: yup, i much prefer re-using the parser, i wasn't able to find that impl,
but should have been more diligent in looking for it.
2. i love the outputSchema decorator pattern that you use.
3. code via a .py file vs. string literal in the constructor. The .py file is a definite win
when dealing with encoding issues (quotes, newlines etc). It's also a cleaner way to import
larger blocks of code, and works for jython files etc. that are used indirectly etc. The constructor
pattern is still supported in my approach, i just use it exclusively for lambda functions.
4. the pyObjToObj code is simpler in your approach, but limits the integration flexibility.
i.e. you explicitly tie tuple:tuple, list:bag. Also, it's not clear how well this would handle
sequences and iterators etc. I personally prefer using the schema to disambiguate the conversion,
so that existing python code can be used to generate bags/tuples etc. via the schema rather
than having to convert python objects using wrapper code.
5. the outputSchema logic is nice (as i said in #2, i love the decorator thing), but the schema
should be cached if it is not a function. If it's a function, then the ref should be cached.
This is particularly important if you're using the schema to inform the python -> pig data
coercion.
6. as i said in prev comments, the scope of the interpreter is important. If you have two
different UDFs that you want to share any state (such as counters), then a shared interpreter
is a good idea. There are also memory gains from sharing etc. In general, i think you rarely
want a distinct interpreter, and as such it should be possible, but not the default.

Anyway, thanks for attaching the submission, i think there are lots of great ideas in your
project. It makes me wish i'd known about it sooner, parsing the pig schema system was not
a fun day, though i guess i did learn a bit from it. The decorator thing is lovely. I'll probably
borrow those and produce a tighter jython and scripting harness at some point.

Overall, i'm still firmly in the multi-language camp, but i think this provides nice improvements
for a jython impl, and can clearly still swallow whatever language support pig introduces
for anyone who wants to drive pig from python. So i think it should still be useful as a standalone
project/harness.


> UDFs in scripting languages
> ---------------------------
>
>                 Key: PIG-928
>                 URL: https://issues.apache.org/jira/browse/PIG-928
>             Project: Pig
>          Issue Type: New Feature
>            Reporter: Alan Gates
>         Attachments: package.zip, pyg.tgz, scripting.tgz, scripting.tgz
>
>
> It should be possible to write UDFs in scripting languages such as python, ruby, etc.
 This frees users from needing to compile Java, generate a jar, etc.  It also opens Pig to
programmers who prefer scripting languages over Java.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message