Adding drill-dev.
Sent from my iPhone > On Nov 15, 2013, at 1:42 AM, Yash Sharma <[email protected]> wrote: > > Hi Tim, hope you are doing great. > I have answered the questions below: > >> Btw looking at the code does it handle where types cannot be casted ie int >> to varchar? > No. Right now I am only checking for implicit/explicit cast. > Still have to put logic for invalid casts. > > One idea is to have categorized precedence maps. Different maps for subsets > of datatypes. Only allowed datatypes will be present in each submap. > Other Idea is to have a separate small map for invalid/restricted type > casts. Code will first check this map, only then it will go for > implicit/explicit cast. This code can be put in the getCost() function in > DrillFunctionHolder class. > >> From your email to the mailing list sounds like you worked around the >> function call change right? > Yes currently I am directly returning the matched function without changing > the function call. It passes test for ADD(FLOAT, INT) but fails for ADD(INT, > FLOAT). > The Provided math functions are ADD(INT, INT) & ADD(FLOAT, FLOAT) > > Thanks, > Yash Sharma > > > > > -----Original Message----- > From: Timothy Chen [mailto:[email protected]] > Sent: Friday, November 15, 2013 4:34 PM > To: Yash Sharma > Subject: Re: Thread for discussing CAST functionality > > Btw looking at the code does it handle where types cannot be casted ie int to > varchar? > > Tim > > Sent from my iPhone > >> On Nov 13, 2013, at 7:25 AM, Yash Sharma <[email protected]> wrote: >> >> Yes you are right - we will have to check func registry for direct match >> first. >> >> Also we don't need to get a common type of the input operands. We can >> directly achieve it by the getCost() function. >> We will select the method which has the minimum Cost. >> If the MIN_COST=0 it means that a direct match is available in function >> registry. >> and if MIN_COST>0 we can directly get the new data types from the method >> implementation, and then convert function call to these data types. >> >> Thoughts? >> >> - Best Regards, Yash >> ________________________________________ >> From: Yash Sharma >> Sent: Wednesday, November 13, 2013 12:29 PM >> To: Timothy Chen >> Subject: RE: Thread for discussing CAST functionality >> >> Yes the flow currently is like: >> >> - First check the function registry with all functions with the name as >> passed-function-name (Class: FunctionImplementationRegistry, method: >> getFunction) >> - Get the list of all functions with that name >> (Class: FunctionImplementationRegistry, method: getFunction) >> - Iterate over the method list to find the exact match >> (Class: DrillFunctionHolder, method: matches) >> >> >> I have introduced the resolvers in the flow, and have got the common >> datatype for the operator. Now need a way to convert the function call. >> By the help of it we would convert the datatype INT, FLOAT to a common type >> FLOAT, FLOAT. >> >> If it is done, next step would be to create a cost() function which will >> compute the cost of conversion to all available function implementations. >> By this we would get something like: >> From, FLOAT, FLOAT >> TO, FLOAT, FLOAT : 0 >> TO, FLOAT, DOUBLE : 1 >> TO, DOUBLE,DOUBLE: 2 >> Etc. >> >> Then we can select the minimum cost function and return it back to user. >> If there are multiple methods with same cost, we return Ambiguous method >> exception. >> >> This is what I have in mind, Let me know your thoughts on it. >> >> Code is up on Github. >> https://github.com/yashs360/incubator-drill-casting >> >> - Best Regards, Yash >> >> From: Timothy Chen [mailto:[email protected]] >> Sent: Wednesday, November 13, 2013 7:08 AM >> To: Yash Sharma >> Subject: Re: Thread for discussing CAST functionality >> >> I think you always want to first search the function registry first right? >> In case there is an exact match. >> >> How about just push this code to your github and we can collaborate from >> there, sounds like we either re-create the function call or perhaps make the >> function call able to identify directly which function it needs to resolve >> on. >> >> Either way you'll need to modify the functionCall a bit to make it work, so >> please feel free to change it! >> >> Tim >> >> On Mon, Nov 11, 2013 at 3:55 AM, Yash Sharma >> <[email protected]<mailto:[email protected]>> wrote: >> Hey Tim, I have started with OperatorResolver, just for '+' operator right >> now. >> >> My steps for matching a function are: >> --------------------------------------------- >> - identify common data type via precedence map >> - modify the function call by user by changing the argument datatypes >> to this common datatype >> - search for implementation of the modified function call >> >> >> I am able to identify the common dataype among two passed data types by >> using a small precedence map. (eg. 2+3.5). >> I now need to convert the FunctionCall to a new call (with new arguments). >> I am not finding any way to modify the function call. >> >> Code: https://gist.github.com/yashs360/7140609 >> The commented part towards the end is the point I am stuck with. >> I will push all the whole code to Github soon and send you the link. >> >> - Thanks, Yash >> >> From: Timothy Chen >> [mailto:[email protected]<mailto:[email protected]>] >> Sent: Sunday, November 10, 2013 12:49 PM >> To: Yash Sharma >> Subject: Re: Thread for discussing CAST functionality >> >> Hi Yash, >> >> Sorry I was referring this morning and things was a bit more hectic today. >> >> I wonder if you want to just start with one prototype and maybe we can do a >> bit ping pong if you need help? >> >> Tim >> >> On Sat, Nov 9, 2013 at 11:25 AM, Yash Sharma >> <[email protected]<mailto:[email protected]>> wrote: >> Tomorrow 10 AM pst - your time.. 11:30 PM ist - my time ? >> Would you be able to make it ? >> ________________________________________ >> From: Yash Sharma >> Sent: Friday, November 08, 2013 11:09 AM >> To: Timothy Chen >> Subject: RE: Thread for discussing CAST functionality >> >> Cool ! >> I am on IST, you give me any time at morning (your time) and I will make it. >> We can have a quick hangout and discuss things, I will do little ground work >> on the proposal till then. >> >> - Yash >> >> >> >> From: Timothy Chen >> [mailto:[email protected]<mailto:[email protected]>] >> Sent: Friday, November 08, 2013 3:26 AM >> To: Yash Sharma >> Subject: Re: Thread for discussing CAST functionality >> >> Hey there, >> >> Sure what time zone are you in? I'm only available at night or morning in >> PST time, so let me know what works for you. >> >> Tim >> On Thu, Nov 7, 2013 at 8:05 AM, Yash Sharma >> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >> wrote: >> Hi Tim, >> Would you be free on the weekend. We can have a small discussion on the >> Casting functionality. >> The idea is to come up with a quick naive prototype of the functionality and >> we can then discuss with everyone on improving it. >> >> Let me know if you are comfortable. >> >> - Yash >> ________________________________________ >> From: Jason Altekruse >> [[email protected]<mailto:[email protected]><mailto:alte >> [email protected]<mailto:[email protected]>>] >> Sent: Wednesday, November 06, 2013 12:45 PM >> To: drill-dev >> Subject: Re: Thread for discussing CAST functionality The last few >> letters were cut off here is the correct link >> >> https://www.dropbox.com/s/puwilz8dv2qp13p/Drillcast%20compatibility.xl >> sx >>> On Tue, Nov 5, 2013 at 11:57 PM, Dhruv >>> <[email protected]<mailto:[email protected]><mailto:[email protected]<mailto:[email protected]>>> >>> wrote: >>> >>> Hi Yash, >>> >>> +1. I am in. >>> I think dropbox link is broken. can you re-check? >>> >>> -Dhruv >>> >>> >>>> On 11/06/2013 11:08 AM, Yash Sharma wrote: >>>> >>>> Hi All, >>>> I see that cast functionality is not moving on with a good pace and >>>> also blocking few other tasks, so thought of making a separate >>>> thread for discussing about it. >>>> I am thinking of putting dedicated hours for Cast functionality this >>>> week so that we can at least have some plan ready for it. >>>> >>>> We can have a dedicated hangout for discussing it too. >>>> Thoughts? >>>> >>>> >>>> JIRA: https://issues.apache.org/jira/browse/DRILL-259 >>>> Proposal Doc: https://docs.google.com/document/d/1HzcWg4uQ42gnz_ >>>> IlgxEzpE2PjPpYvgPjkHyfA04vCac/edit#<https://docs.google.com/ >>>> document/d/1HzcWg4uQ42gnz_IlgxEzpE2PjPpYvgPjkHyfA04vCac/edit> >>>> >>>> Type cast compatibility chart: https://www.dropbox.com/s/ >>>> puwilz8dv2qp13p/Drillcast%20compatibility.xl >>>> >>>> >>>> - Yash >>>> >>>> >>>> ________________________________ >>>> >>>> >>>> >>>> >>>> >>>> >>>> NOTE: This message may contain information that is confidential, >>>> proprietary, privileged or otherwise protected by law. The message >>>> is intended solely for the named addressee. If received in error, >>>> please destroy and notify the sender. Any use of this email is >>>> prohibited when received in error. Impetus does not represent, >>>> warrant and/or guarantee, that the integrity of this communication >>>> has been maintained nor that the communication is free of errors, virus, >>>> interception or interference. >> >> ________________________________ >> >> >> >> >> >> >> NOTE: This message may contain information that is confidential, >> proprietary, privileged or otherwise protected by law. The message is >> intended solely for the named addressee. If received in error, please >> destroy and notify the sender. Any use of this email is prohibited when >> received in error. Impetus does not represent, warrant and/or guarantee, >> that the integrity of this communication has been maintained nor that the >> communication is free of errors, virus, interception or interference. >> >> >> ________________________________ >> >> >> >> >> >> >> NOTE: This message may contain information that is confidential, >> proprietary, privileged or otherwise protected by law. The message is >> intended solely for the named addressee. If received in error, please >> destroy and notify the sender. Any use of this email is prohibited when >> received in error. Impetus does not represent, warrant and/or guarantee, >> that the integrity of this communication has been maintained nor that the >> communication is free of errors, virus, interception or interference. >> >> >> ________________________________ >> >> >> >> >> >> >> NOTE: This message may contain information that is confidential, >> proprietary, privileged or otherwise protected by law. The message is >> intended solely for the named addressee. If received in error, please >> destroy and notify the sender. Any use of this email is prohibited when >> received in error. Impetus does not represent, warrant and/or guarantee, >> that the integrity of this communication has been maintained nor that the >> communication is free of errors, virus, interception or interference. >> >> >> ________________________________ >> >> >> >> >> >> >> NOTE: This message may contain information that is confidential, >> proprietary, privileged or otherwise protected by law. The message is >> intended solely for the named addressee. If received in error, please >> destroy and notify the sender. Any use of this email is prohibited when >> received in error. Impetus does not represent, warrant and/or guarantee, >> that the integrity of this communication has been maintained nor that the >> communication is free of errors, virus, interception or interference. > > ________________________________ > > > > > > > NOTE: This message may contain information that is confidential, proprietary, > privileged or otherwise protected by law. The message is intended solely for > the named addressee. If received in error, please destroy and notify the > sender. Any use of this email is prohibited when received in error. Impetus > does not represent, warrant and/or guarantee, that the integrity of this > communication has been maintained nor that the communication is free of > errors, virus, interception or interference.
