Replies: 10 comments
-
Could you elaborate on the use case? |
Beta Was this translation helpful? Give feedback.
-
In spark toString is overridden (not sure if it is always or just sometimes) so doing: col("a").toString returns a string "a" if you do that on a Col in .NET you get: Col("a").ToString() returns a string "Microsoft.Spark.Sql.Column". It feels like if we forwarded ToString and Equals then we will be more consistent with whatever spark does (or doesn't if it doesn't override them in some cases). |
Beta Was this translation helpful? Give feedback.
-
Got it. Yea, I think we can forward them to Scala side. |
Beta Was this translation helpful? Give feedback.
-
Thanks, Will do |
Beta Was this translation helpful? Give feedback.
-
I am curious what the notebook experience will be like since it depends on |
Beta Was this translation helpful? Give feedback.
-
There may be some unintended side effects by override Equals ? One example may be if a user is adding/checking these jvm objects against C# dictionary/hashset, any collisions would create jvm calls. |
Beta Was this translation helpful? Give feedback.
-
I don't see anything too concerning with toString with notebooks atm. |
Beta Was this translation helpful? Give feedback.
-
I am thinking we should support |
Beta Was this translation helpful? Give feedback.
-
I’d say pass toString on, this is another example: #594 |
Beta Was this translation helpful? Give feedback.
-
Yea, we can start with |
Beta Was this translation helpful? Give feedback.
-
Does it make sense to override these in spark objects and pass them back to the JVM (or provide our own implementation)?
Is there a preference for overriding or not overriding? I did a quick search and could see a few "override ToString" so wasn't sure what to do.
Beta Was this translation helpful? Give feedback.
All reactions