Skip to content

Conversation

@schot
Copy link

@schot schot commented Nov 17, 2015

I have tried to address all the comments in pull request #2447.

Note that the second commit (using the new method in all internal code of all components) is quite intrusive and could be omitted.

@srowen
Copy link
Member

srowen commented Nov 17, 2015

This is such a noisy change for really little gain that I don't think it's worth it. At best just ensure there is a getNumPartitions in each language.

@schot
Copy link
Author

schot commented Nov 17, 2015

Although it would be nice to fix the inconsistencies in the usage of partitions.length vs partitions.size, I agree that its better to stick to just adding getNumPartitions. I will remove the second commit from the PR.

Should we also add a getNumPartitions method to JavaRDDLike for the Java API?

@srowen
Copy link
Member

srowen commented Nov 17, 2015

Yes, ideally. @JoshRosen am I right that we have to add the new method to the JavaRDDLike trait or the abstract class that implements it in order to avoid binary incompatibility? Both?

@schot schot changed the title [SPARK-3580] Add Consistent Method To Get Number of RDD Partitions Across Different Languages [SPARK-3580][CORE] Add Consistent Method To Get Number of RDD Partitions Across Different Languages Nov 17, 2015
@schot
Copy link
Author

schot commented Nov 17, 2015

If I understand the discussion in SPARK-3266 correctly the method should only be added to the JavaRRDLike trait and not the abstract class.

I have updated the PR with this change.

@JoshRosen
Copy link
Contributor

Yeah, AFAIK you only need to add it to the trait.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mind adding a @since tag here to say that this is new in Spark 1.6?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not at all. Should I use @since or @Since, and also add it to RDD.scala? (I could not find any occurrence of this tag in spark-core).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I added the @Since tags and updated this PR.

@srowen
Copy link
Member

srowen commented Nov 21, 2015

I think this looks good.

@SparkQA
Copy link

SparkQA commented Nov 21, 2015

Test build #2094 has finished for PR 9767 at commit 2324016.

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

@srowen
Copy link
Member

srowen commented Nov 23, 2015

@schot I think you will have to add the MiMa exclude that the error message in the output mentions. It's a 'false positive' but MiMa needs to be reassured.

@schot
Copy link
Author

schot commented Nov 23, 2015

@srowen Yes, I added a Mima exclude.

@schot
Copy link
Author

schot commented Nov 25, 2015

Because I merged the fix in the previous commit Jenkins retest does not happen automatically?

@SparkQA
Copy link

SparkQA commented Nov 25, 2015

Test build #2111 has finished for PR 9767 at commit fb5dcdf.

  • This patch passes all tests.
  • This patch merges cleanly.
  • This patch adds no public classes.

@srowen
Copy link
Member

srowen commented Nov 28, 2015

@schot this'll need a rebase. @JoshRosen are you OK with this for 1.6?

This patch adds a new method getNumPartitions to the Scala RDD and
JavaRDDLike APIs as proposed in [SPARK-3580]. It brings the Scala and
Java APIs in line with the Python API. For the Java API we added a Mima
exclude.
@schot
Copy link
Author

schot commented Nov 28, 2015

@srowen @JoshRosen PR has been rebased to resolve the conflict on MimaExcludes.

@srowen
Copy link
Member

srowen commented Dec 1, 2015

Pinging @JoshRosen @pwendell for an opinion on slipping this into 1.6. I'm still inclined to put it in but I'm aware this week there's a more conservative stance on 1.6. I wanted to wait a day before I did this.

@pwendell
Copy link
Contributor

pwendell commented Dec 2, 2015

Yeah I think it's fine to pull in - but do it quickly because an RC will go out very soon!

@asfgit asfgit closed this in 128c290 Dec 2, 2015
asfgit pushed a commit that referenced this pull request Dec 2, 2015
…ons Across Different Languages

I have tried to address all the comments in pull request #2447.

Note that the second commit (using the new method in all internal code of all components) is quite intrusive and could be omitted.

Author: Jeroen Schot <[email protected]>

Closes #9767 from schot/master.

(cherry picked from commit 128c290)
Signed-off-by: Sean Owen <[email protected]>
@srowen
Copy link
Member

srowen commented Dec 2, 2015

merged to master / 1.6

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.

5 participants