Skip to content

Conversation

@szheng79
Copy link
Contributor

This is a trial change, is useful in java (because java developer can't benefit from getAs[T] method).

This is a trial change, is useful in java (because java developer can't benefit from getAs[T] method).
@rxin
Copy link
Contributor

rxin commented Apr 29, 2015

Why can't Java user use getAs[T]?

@srowen
Copy link
Member

srowen commented Apr 29, 2015

@szheng79 this has nothing to do with SPARK-6994

@szheng79
Copy link
Contributor Author

@rxin I just think it is best for a java developer has more specific way to control the return type. Like current there is these version of methods to access row by index.

Because I move my code base from getString(int) like method, so it is a bit lazy for me to change everywhere. So I think if I need to have these helper method, I just add them to the code, so make it consistent with current method style.

Simply use getAs method can't give direct result type to compiler, so sometimes it will enforce class cast (in java) to tell what it the result type:

For example:
we can write:
row.getString("MAXDEDCUR").length()
But with getAs
((String)row.getAs("MAXDEDCUR")).length();

I just realize this is same case in scala? Is it the reason why so many getTYPE(int index) method there?

But I have no preference on whether we must have this. If here people think we better don't have these, I will delete the pull request :).

And to me, if we don't have these, I will say we better only keep getAs(int) and getAs(String), instead of only have getString(int index) like method without similar getString(String fieldName)

@szheng79
Copy link
Contributor Author

@srowen I say it is with SPARK-6994, because the implementation must based on SPARK-6994 change. And because this is a very minor change, I don't want to hijack other people's credit. So I just put it under 6994

@srowen
Copy link
Member

srowen commented Apr 29, 2015

That's my fault. I typed the wrong JIRA. Yes it is related.

@vidma
Copy link

vidma commented May 1, 2015

P.S. I'd say getAs should (kinda) work in Java too:

String s = row.getAs(1);

Anyway, one advantage of having dozen of methods for primitive types is to avoid boxing. In scala, @specialize annotation might do, but clearly in Java one needs something like in this PR.

so looks 🆗 to me.

@vidma
Copy link

vidma commented May 3, 2015

@szheng79 please add to this PR the updated Spark-SQL docs for Java from this branch: https://github.com/apache/spark/compare/master...vidma:docs/row-with-named-fields-java?expand=1

@marmbrus
Copy link
Contributor

ok to test

@SparkQA
Copy link

SparkQA commented Jun 12, 2015

Test build #34744 has finished for PR 5754 at commit 9c774f6.

  • This patch fails Scala style tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@rxin
Copy link
Contributor

rxin commented Jul 13, 2015

@szheng79 do you mind bringing this up to date? I think we can merge this then. Thanks.

@AmplabJenkins
Copy link

Can one of the admins verify this patch?

@andrewor14
Copy link
Contributor

ping @szheng79 can you rebase to master?

@rxin
Copy link
Contributor

rxin commented Dec 31, 2015

I'm going to close this pull request. If this is still relevant and you are interested in pushing it forward, please open a new pull request. Thanks!

@asfgit asfgit closed this in 7b4452b Dec 31, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants