These are chat archives for CommBank/maestro

8th
Apr 2015
Rowan Davies
@rowandavies
Apr 08 2015 00:24
@SamRoberts #354 looks good, I have just one picky suggestion, which you can decide on. :+1:
Luke Williams
@shmookey
Apr 08 2015 00:36
@rowandavies can try this assembly whenever you're ready :)
Gavin Whyte
@gavinwhyte
Apr 08 2015 00:55
@vineethvarghese The omnia virtual repository association has been added
Vineeth Varghese
@vineethvarghese
Apr 08 2015 00:56
@gavinwhyte thanks will test it out
Gavin Whyte
@gavinwhyte
Apr 08 2015 00:56
no worries
Rowan Davies
@rowandavies
Apr 08 2015 01:36
@shmookey I’ll be ready in 10mins or so.
Rowan Davies
@rowandavies
Apr 08 2015 02:02
Or so…
Rowan Davies
@rowandavies
Apr 08 2015 02:37
@shmookey Okay, I’m ready when you are.
Stephan Hoermann
@stephanh
Apr 08 2015 02:41
Not feeling so great and can't get any work done. I'm going to head home.
Vineeth Varghese
@vineethvarghese
Apr 08 2015 03:31
Can someone please review CommBank/etl-controller#3 soon :)
Rowan Davies
@rowandavies
Apr 08 2015 04:06
@vineethvarghese CommBank/etl-controller#3 looks good. :+1:
Vineeth Varghese
@vineethvarghese
Apr 08 2015 04:07
Thanks @rowandavies and @SamRoberts
Rowan Davies
@rowandavies
Apr 08 2015 04:07
Oh, sam beat me. :-)
Luke Williams
@shmookey
Apr 08 2015 04:46
@stephanh hope you feel better soon!
ok, got the transform stuff working in a more functional style, this is what an invocation looks like now:
@transformer
val foobar2:(Foo,Bar) => FooBar = (
  thatInt    => Foo.thisInt,
  thatString => Bar.thisString
)
(where foobar2 is the generated mapping function...)
the generated code looks like this:
val foobar2: root.scala.Function2[Foo, Bar, FooBar] = ((x1: Foo, x2: Bar) => {
val r = new FooBar();
r.x = x1.x;
r.y = x2.y;
r.thatInt = x1.thisInt;
r.thatString = x2.thisString;
return r
})
Sam Roberts
@SamRoberts
Apr 08 2015 05:25
Minor: don't we need to generate Function1[(Foo,Bar),FooBar], in order to use this on joined pipes and so forth?
What happens by default when a field is defined in both x1 and x2?
Will it keep the existing Join behaviour?
The syntax, on first impressions, really looks awesome
Not sure this is a valid use-case, but what happens if you are joining a tuple of objects with the same type?
Luke Williams
@shmookey
Apr 08 2015 05:46
good points
it more or less keeps the existing join behaviour, i think
if a field is defined in both structs, the first struct in the parameter list is used
Sam Roberts
@SamRoberts
Apr 08 2015 05:47
that's not the existing behaviour though
Luke Williams
@shmookey
Apr 08 2015 05:47
oh?
what happens now?
Vineeth Varghese
@vineethvarghese
Apr 08 2015 05:48
shouldn't it fail?
Sam Roberts
@SamRoberts
Apr 08 2015 05:48
the existing behaviour is to check that the field value is unambiguous (has the same value in all structs), and throw an exception if it isn't
the reason for that particular behaviour is that we are thinking this will primarily be used after a join, and fields with the same name should be join fields
Luke Williams
@shmookey
Apr 08 2015 05:51
ah
simple enough to throw an exception
what do you mean by join fields?
like, in the sql sense?
Sam Roberts
@SamRoberts
Apr 08 2015 05:52
fields used to join two pipes together
Sam Roberts
@SamRoberts
Apr 08 2015 06:06
I think the syntax shouldn'
shouldn't really re-use function syntax, as a) it's not really the right metaphor (the lhs is the output field, not an input parameter), and b) we might in the future want to allow users to specify straight scala functions to avoid any issues that the special syntax might not be able to handle
so maybe something like (thatInt := Foo.thisInt, thatString := Bar.thisString) ?
Luke Williams
@shmookey
Apr 08 2015 06:21
yep sounds good :)
Luke Williams
@shmookey
Apr 08 2015 07:04
cool, seems to be working
Todd Owen
@toddmowen
Apr 08 2015 12:00
Just to repeat this message for everyone who Needs To Know, I will generally be working Mon/Wed/Fri each week.
Vineeth Varghese
@vineethvarghese
Apr 08 2015 14:45
Can someone please review CommBank/answer#9
I will be working from home tomorrow. Please give me a call for the standup.
Vineeth Varghese
@vineethvarghese
Apr 08 2015 21:59
@stephan to make answer public, I presume all we need to do is change the keys and Travis will automatically pick it up. Or do I need to go via the travis cli client again?
Vineeth Varghese
@vineethvarghese
Apr 08 2015 23:20
Do we have a monoid defined for JobStatus some where?
Stephan Hoermann
@stephanh
Apr 08 2015 23:22
@vineethvarghese you will need to enable the build for open source travis
Vineeth Varghese
@vineethvarghese
Apr 08 2015 23:23
cool
Sam Roberts
@SamRoberts
Apr 08 2015 23:24
I don't think so. I vaguely remember discussing one some time ago, but I don't think there are any "obviously correct" semantics that would apply everywhere (e.g., given two errors, how to combine them? There are many ways and different ways are going to be appropriate in different situations)
Vineeth Varghese
@vineethvarghese
Apr 08 2015 23:30
In theory it can't generic although I see similarities btw the monoid I wrote for farlo and payment journal and was wondering whether anyone else faced this and ended up writing something.