Fix to use physical name instead of logical name to retrieve available interval #226

garyluoex · 2017-04-04T16:14:40Z

Added PhysicalDataSourceConstraint class to capture physical names of columns for retrieving availble interval
getAllAvailbleIntervals in ConcreteAvailability no longer filters out unconfigured columns, instead table's getAllAvailbleIntervals does
getAvailbleIntervals in Availbality now takes PhysicalDataSourceConstraint instead of DataSourceConstraint
Availbility no longer takes a set of columns on the table, only table needs to know
getAllAvailbleIntervals in Availbility now returns a map of column physical name to interval list instead of column to interval list
TestDataSourceMetadataService now takes map from string to list of intervals instead of column to list of intervals for constructor

cdeszaq

Needs CHANGELOG

cdeszaq · 2017-04-04T16:20:33Z

fili-core/src/main/java/com/yahoo/bard/webservice/table/BasePhysicalTable.java

+                .collect(Collectors.toMap(
+                        Function.identity(),
+                        column -> availableIntervals.get(getSchema().getPhysicalColumnName(column.getName()))
+                ));


I think this should wrap down 1 more level (ie. unwrap the .collect(Collectors.toMap( line, and corresponding )); line

cdeszaq · 2017-04-04T20:15:06Z

fili-core/src/main/java/com/yahoo/bard/webservice/table/BasePhysicalTable.java

+        return getSchema().getColumns().stream()
+                .collect(Collectors.toMap(
+                        Function.identity(),
+                        column -> availableIntervals.get(getSchema().getPhysicalColumnName(column.getName()))


Should this be getOrDefault?

cdeszaq · 2017-04-04T20:24:28Z

fili-core/src/main/java/com/yahoo/bard/webservice/table/availability/ConcreteAvailability.java

@@ -106,7 +104,7 @@ public SimplifiedIntervalList getAvailableIntervals(DataSourceConstraint constra
        return metadataService.getAvailableIntervalsByTable(name);
    }

-    protected Set<String> getColumnNames() {
-        return columnNames;
+    protected Set<String> getColumnPhysicalNames() {


Should we rename this physicalColumnNames? columnPhysicalNames feels a bit backwards, for some reason.

Same reason as we don't have physicalColumn names

cdeszaq · 2017-04-04T20:25:11Z

fili-core/src/main/java/com/yahoo/bard/webservice/table/resolver/DataSourceConstraint.java

+     *
+     * @param dataSourceConstraint  The data source constarint to copy from
+     */
+    public DataSourceConstraint(DataSourceConstraint dataSourceConstraint) {


Should be protected, not public

cdeszaq · 2017-04-04T20:25:41Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+     *
+     * @return the physical name of all the columns
+     */
+    public Set<String> getAllColumnPhysicalNames() {


Should we rename this physicalColumnNames? columnPhysicalNames feels a bit backwards, for some reason.

We don't have PhysicalColumns, we do have Column physical names.

I see it more as having the "physical" "column names", rather than "physical column" "names", but I suppose it's not a big difference either way 😄

cdeszaq · 2017-04-04T20:27:19Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+     * @param dataSourceConstraint  Data soruce contraint containing all the column names as logical names
+     * @param physicalTableSchema  A map from logical column name to physical column names
+     */
+    public PhysicalDataSourceConstraint(DataSourceConstraint dataSourceConstraint, PhysicalTableSchema physicalTableSchema) {


Rather than depending on the PhysicalTableSchema, we should just take the one mapping function we care about:

Function<String, String> logicalToPhysicalNameMapper

We also need all the columns from it, might as well pass the entire schema.

michael-mclawhorn

I think moving the toNames... mapping to schema will greatly simplify this.
It'll also need tests.

michael-mclawhorn · 2017-04-05T19:05:31Z

CHANGELOG.md

+- [Fix to use physical name instead of logical name to retrieve available interval](https://github.com/yahoo/fili/pull/226)
+    * `getAllAvailbleIntervals` in `ConcreteAvailability` no longer filters out unconfigured columns, instead table's `getAllAvailbleIntervals` does
+    * `getAvailbleIntervals` in `Availbality` now takes `PhysicalDataSourceConstraint` instead of `DataSourceConstraint`
+    * `Availbility` no longer takes a set of columns on the table, only table needs to know


Spelling error in Availability

michael-mclawhorn · 2017-04-05T19:10:08Z

CHANGELOG.md

+    * `getAvailbleIntervals` in `Availbality` now takes `PhysicalDataSourceConstraint` instead of `DataSourceConstraint`
+    * `Availbility` no longer takes a set of columns on the table, only table needs to know
+    * `getAllAvailbleIntervals` in `Availbility` now returns a map of column physical name to interval list instead of column to interval list
+    * `TestDataSourceMetadataService` now takes map from string to list of intervals instead of column to list of intervals for constructor


Availbility -> Availability

michael-mclawhorn · 2017-04-05T20:19:54Z

...-core/src/main/java/com/yahoo/bard/webservice/table/availability/PermissiveAvailability.java

+    public SimplifiedIntervalList getAvailableIntervals(PhysicalDataSourceConstraint constraint) {
+        Map<String, List<Interval>> allAvailableIntervals = getAllAvailableIntervals();
+
+        return constraint.getAllColumnPhysicalNames().stream()


This is a change in behavior and I don't think it is correct.

While I think @garyluoex is right, in that it should work as long as PhysicalDataSourceConstraint::buildWithSchemaUnion does the right thing. That said, I think the JavaDoc on this method needs significant upgrades to reflect the new assumptions this method has, in that the unioning needs to have already been done to the inbound constraint object.

And with this new formulation, there is significant overlap between this method and the method in ConcreteAvailability, even though they do it a little differently. Here are the relevant portions:

// ConcreteAvailability .map(physicalName -> allAvailableIntervals.getOrDefault(physicalName, Collections.emptyList())) .map(intervals -> (Collection<Interval>) intervals) .reduce(null, IntervalUtils::getOverlappingSubintervals) // PermissiveAvailability .map(columnName -> allAvailableIntervals.getOrDefault(columnName, Collections.emptyList())) .flatMap(List::stream) .collect(SimplifiedIntervalList.getCollector());

If that core can be lifted into a common protected helper in ConcreteAvailability, that would be nice.

michael-mclawhorn · 2017-04-05T20:21:47Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+        Set<String> schemaColumnNames = physicalTableSchema.getColumns().stream()
+                .map(Column::getName)
+                .collect(Collectors.toSet());
+


This should just be a get method on physical table schema

Now that there is such a method, this code should use it 😉

michael-mclawhorn

Please move:

   Set<String> schemaColumnNames = physicalTableSchema.getColumns().stream()

```
           .map(Column::getName)
```

           .collect(Collectors.toSet());

behavior to the schema class as a get method.

Also, I believe permissive availability is incorrect. Constraints should be ignored for getAvailableIntervals.

michael-mclawhorn · 2017-04-12T16:31:22Z

...-core/src/main/java/com/yahoo/bard/webservice/table/availability/PermissiveAvailability.java

     * Instead of returning the intersection of all available intervals, this method returns the union of them.
     *
-     * @param ignoredConstraints  Data constraint containing columns and api filters. Constrains are ignored, because
+     * @param constraint  Data constraint containing columns and api filters. Constrains are ignored, because


Why was this changed? I'm pretty sure that the original 'ignored' was intentional.
Also, spelling 'Constraints'

michael-mclawhorn · 2017-04-12T16:36:47Z

...c/test/groovy/com/yahoo/bard/webservice/table/availability/PermissiveAvailabilitySpec.groovy

@@ -49,15 +50,14 @@ class PermissiveAvailabilitySpec extends Specification  {



This test is incorrect to design. Create a 'long_interval' column and confirm that even when not selecte that the getAvailableIntervals()l is always the long_interval or the union of the long_interval with any non overlapping intervals.

What? I'm not sure I understand the problem here...

Basically a column that doesn't participate at all should still overwhelm everything else if it's big in time.

QubitPi · 2017-04-12T17:52:52Z

fili-core/src/main/java/com/yahoo/bard/webservice/table/resolver/DataSourceConstraint.java

+        this.allDimensions = dataSourceConstraint.getAllDimensions();
+        this.allDimensionNames = this.getAllDimensionNames();
+        this.allColumnNames = this.getAllColumnNames();
+    }


Since all private instance variables are final, should we use defensive copy? @cdeszaq @michael-mclawhorn

In general, protected and private constructors like this are relying on the fact that the external interfaces are ensuring the collections like this are immutable, so there's usually no need to defensively copy collections for those sorts of copy-constructors.

tldr: In this case, it's OK to use the item directly, not need to defensively copy

QubitPi · 2017-04-12T17:53:55Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+     * @param physicalTableSchema  A map from logical column name to physical column names
+     */
+    public PhysicalDataSourceConstraint(
+            DataSourceConstraint dataSourceConstraint,


Are we missing @NotNull?

QubitPi · 2017-04-12T17:54:14Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+     */
+    public PhysicalDataSourceConstraint(
+            DataSourceConstraint dataSourceConstraint,
+            PhysicalTableSchema physicalTableSchema


Are we missing @NotNull?

QubitPi · 2017-04-12T17:55:24Z

fili-core/src/test/groovy/com/yahoo/bard/webservice/data/QueryBuildingTestingResources.groovy


        [d1, d2, m1, m2, m3].each {
-            availabilityMap1.put(toColumn(it), [interval1].toSet())
-            availabilityMap2.put(toColumn(it), [interval2].toSet())
+            availabilityMap1.put(toColumn(it).getName(), [interval1].toSet())


I guess [interval1] as Set is more readable?

QubitPi · 2017-04-12T17:56:32Z

...src/test/groovy/com/yahoo/bard/webservice/table/availability/ConcreteAvailabilitySpec.groovy

-                        (new Column('ignored')): [new Interval('2010-01-01/2500-12-31')] as Set
+                        (columnPhysicalName1): [interval1] as Set,
+                        (columnPhysicalName2): [interval2] as Set,
+                        'hidden_column'     : [interval1] as Set


small - colon allignment

QubitPi · 2017-04-12T17:56:47Z

...src/test/groovy/com/yahoo/bard/webservice/table/availability/ConcreteAvailabilitySpec.groovy

-                (column3): [],
+                (columnPhysicalName1): [interval1],
+                (columnPhysicalName2): [interval2],
+                'hidden_column'     : [interval1],


small - colon allignment

cdeszaq

I didn't go deeply into the tests, but I got through the rest of it.

cdeszaq · 2017-04-12T19:11:26Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+        this.allColumnPhysicalNames = dataSourceConstraint.getAllColumnNames().stream()
+                .filter(schemaColumnNames::contains)
+                .map(physicalTableSchema::getPhysicalColumnName)
+                .collect(Collectors.toSet());


This needs to be made unmodifiable, so that when we expose it through the getter, it's not messed with. Collectors.collectinAndThen is a useful tool for this task.

Still needs to be addressed

cdeszaq · 2017-04-12T19:11:54Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+
+        this.allColumnPhysicalNames = schemaColumnNames.stream()
+                .map(physicalTableSchema::getPhysicalColumnName)
+                .collect(Collectors.toSet());


This needs to be made unmodifiable, so that when we expose it through the getter, it's not messed with. Collectors.collectinAndThen is a useful tool for this task.

cdeszaq · 2017-04-12T19:14:23Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+     */
+    private PhysicalDataSourceConstraint(
+            PhysicalTableSchema physicalTableSchema,
+            DataSourceConstraint dataSourceConstraint


We should definitely not have 2 constructors that only differ by the order of their parameters. We should find a better way to do this.

One idea that comes to mind would be to have a private constructor that takes the dataSourceConsraint and the collection of allColumnPhysicalNames directly, and then allow the "smarts" to be handled elsewhere.

cdeszaq · 2017-04-12T19:19:06Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+    }
+
+    /**
+     * Private Constructor that union columns in constraint and schema, use buildWithSchemaUnion to invoke.


This constructor doesn't look like it does a union of the columns in the constraint and the schema. It looks like it's only pulling columns from the schema. Am I missing something?

cdeszaq · 2017-04-12T19:20:33Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+                .collect(Collectors.toSet());
+
+        this.allColumnPhysicalNames = schemaColumnNames.stream()
+                .map(physicalTableSchema::getPhysicalColumnName)


At least part of this processing is shared between the two constructors:

this.allColumnPhysicalNames = <columnNames>.stream() .map(physicalTableSchema::getPhysicalColumnName) .collect(Collectors.collectingAndThen(Collectors.toSet(), Collections::unmodifiableSet));

It would be nice to remove this duplication.

cdeszaq · 2017-04-12T19:22:54Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+     *
+     * @return a new physical data source constraint with all columns in schema
+     */
+    public static PhysicalDataSourceConstraint buildWithSchemaUnion(


This seems to never be called by a test. Perhaps it should be?

cdeszaq · 2017-04-12T19:49:22Z

fili-core/src/main/java/com/yahoo/bard/webservice/table/BasePhysicalTable.java

@@ -79,12 +82,21 @@ public DateTime getTableAlignment() {

    @Override


Should JavaDoc be added here to call out the filtering that happens so that only columns that are in the Schema for this table are returned?

Still needs to be addressed I think?

added comment on the interface

cdeszaq · 2017-04-12T20:11:36Z

fili-core/src/main/java/com/yahoo/bard/webservice/table/PermissiveConcretePhysicalTable.java

+        return getAvailability().getAvailableIntervals(PhysicalDataSourceConstraint.buildWithSchemaUnion(
+                constraint,
+                getSchema()
+        ));


This should wrap differently:

return getAvailability().getAvailableIntervals( PhysicalDataSourceConstraint.buildWithSchemaUnion(constraint, getSchema()) );

In general, the outer-most param list is where the wrapping should occur, rather than the inner-most, in a case like this where there are nested calls.

cdeszaq · 2017-04-12T20:18:03Z

fili-core/src/main/java/com/yahoo/bard/webservice/table/availability/ConcreteAvailability.java


        // Need to ensure requestColumns is not empty in order to prevent returning null by reduce operation
        return new SimplifiedIntervalList(
                requestColumns.stream()
-                        .map(columnName -> allAvailableIntervals.getOrDefault(columnName, Collections.emptyList()))
+                        .map(physicalName -> allAvailableIntervals.getOrDefault(physicalName, Collections.emptyList()))


Does it make sense to use new SimplifiedIntervalList() instead of Collections.emptyList() for the default value here? It would bring it in line with what getAllAvailableIntervals() is doing in the BasePhysicalTable.

It may also allow for some optimizations or smarts with the rest of this stream, possibly letting us drop the wrapping construction of new SimplifiedIntervalList that is ultimately getting returned here if we can build one from this stream directly...

I would change things to Collections.emptyList since it is shorter and looks less expensive than creating a new SimplifiedIntervalList, let me know otherwise.

I think this should use a SIL as it's default. The biggest reasons is that it allows the following map and reduce calls to use SIL-aware methods which can be faster, since an SIL has known ordering and compactness qualities that a List does not. It also allows the SIL produced by that reduction to be returned directly, rather than having to convert a List into an SIL.

So, while Collections.emptyList() may seem shorter and faster than new SimplifiedIntervalList(), the net result may actually be that using SIL everywhere is faster overall.

Still needs addressing?

cdeszaq · 2017-04-12T20:52:47Z

...-core/src/main/java/com/yahoo/bard/webservice/table/availability/PermissiveAvailability.java

+    public SimplifiedIntervalList getAvailableIntervals(PhysicalDataSourceConstraint constraint) {
+        Map<String, List<Interval>> allAvailableIntervals = getAllAvailableIntervals();
+
+        return constraint.getAllColumnPhysicalNames().stream()


While I think @garyluoex is right, in that it should work as long as PhysicalDataSourceConstraint::buildWithSchemaUnion does the right thing. That said, I think the JavaDoc on this method needs significant upgrades to reflect the new assumptions this method has, in that the unioning needs to have already been done to the inbound constraint object.

And with this new formulation, there is significant overlap between this method and the method in ConcreteAvailability, even though they do it a little differently. Here are the relevant portions:

// ConcreteAvailability .map(physicalName -> allAvailableIntervals.getOrDefault(physicalName, Collections.emptyList())) .map(intervals -> (Collection<Interval>) intervals) .reduce(null, IntervalUtils::getOverlappingSubintervals) // PermissiveAvailability .map(columnName -> allAvailableIntervals.getOrDefault(columnName, Collections.emptyList())) .flatMap(List::stream) .collect(SimplifiedIntervalList.getCollector());

If that core can be lifted into a common protected helper in ConcreteAvailability, that would be nice.

michael-mclawhorn

I think all my concerns are answered.

cdeszaq

I think there's just 3 things outstanding from my perspective. I've commented on those items indicating they still need to be addressed.

Also, this needs to be rebased onto master.

cdeszaq

Just a few more small changes

cdeszaq · 2017-04-13T22:08:41Z

...core/src/main/java/com/yahoo/bard/webservice/table/availability/MetricUnionAvailability.java

-        // get a map from availability to its available metric columns intersected with configured metric columns
-        // i.e. metricColumns
-        availabilitiesToAvailableColumns = physicalTables.stream()
+        // map each metric to its corresponding availability object


This comment change is losing the fact that this is intersected with the configured (ie. passed in) metric columns.

This comment change is also losing the fact that this is building Map<Availability, Set<metric column>>, rather than Map<metric column, Availability>, which seems to be what the comment is saying

cdeszaq · 2017-04-13T22:18:29Z

...core/src/main/java/com/yahoo/bard/webservice/table/availability/MetricUnionAvailability.java

-                                Map.Entry::getValue
-                        )
-                );
+        return availabilityToMetricNames.entrySet().stream()


Could just use .values() and skip the extra map operation

cdeszaq · 2017-04-13T22:20:21Z

...-core/src/main/java/com/yahoo/bard/webservice/table/availability/PermissiveAvailability.java

-                getName().asName(),
-                getColumnNames()
+        return String.format("PermissiveAvailability with table name = %s",
+                getName().asName()
        );


Doesn't need to wrap?

cdeszaq · 2017-04-13T22:20:39Z

...-core/src/main/java/com/yahoo/bard/webservice/table/availability/PermissiveAvailability.java

-                .flatMap(List::stream)
-                .collect(SimplifiedIntervalList.getCollector());
+    public SimplifiedIntervalList getAvailableIntervals(PhysicalDataSourceConstraint ignoredConstraint) {
+


Can remove blank line

cdeszaq · 2017-04-13T22:23:35Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

+     * @param apiFilters  Map of dimension to its set of API filters
+     * @param allColumnPhysicalNames  Set of all column physical names
+     */
+    protected PhysicalDataSourceConstraint(


Why do we have this constructor? It looks like it does exactly the same thing as the private constructor just above, except unpacks the parameters. Can we remove this one?

cdeszaq · 2017-04-13T22:27:24Z

.../test/groovy/com/yahoo/bard/webservice/table/availability/MetricUnionAvailabilitySpec.groovy

-        Set<MetricColumn> availableColumns2 = availabilitiesToAvailableColumns.get(availability2)
-        availableColumns2.contains(metricColumn2)
+        Set<String> availableColumns2 = availabilitiesToAvailableColumns.get(availability2)
+        availableColumns2.contains(metric2)
        !availableColumns2.contains(tableColumn1)
        !availableColumns2.contains(tableColumn2)
    }

    @Unroll
    def "checkDuplicateValue returns duplicate metric column names or empty, if no duplicates, from 2 physical tables in the case of #caseDescription"() {


Test name needs to be updated

cdeszaq · 2017-04-14T17:42:43Z

...ore/src/main/java/com/yahoo/bard/webservice/table/resolver/PhysicalDataSourceConstraint.java

@@ -41,7 +38,7 @@ public PhysicalDataSourceConstraint(
    }

    /**
-     * Constructor, use with care, beware of caching behavior.
+     * Constructor, use with care, beware of inconsistent caching behavior.


I think I'm still confused. What inconsistencies are possible?

cdeszaq

Just a couple small questions. Otherwise this is good.

michael-mclawhorn

Almost there from my point of view.
I think we should take on handling the 'requested but not mapped' metric column bug even if the SchemaTableResolver is currently protecting us from the worst risk.

michael-mclawhorn · 2017-04-14T16:22:08Z

.../test/groovy/com/yahoo/bard/webservice/table/availability/MetricUnionAvailabilitySpec.groovy

@@ -163,6 +171,36 @@ class MetricUnionAvailabilitySpec extends Specification {

    }

+    def "constructSubConstraint correctly intersect metrics configured on the table with the metrics supported by availability's underlying datasource"() {
+        given:


subject/verb agreement: 'intersects'

michael-mclawhorn · 2017-04-14T16:38:04Z

.../test/groovy/com/yahoo/bard/webservice/table/availability/MetricUnionAvailabilitySpec.groovy

+        expect:
+        metricUnionAvailability.constructSubConstraint(physicalDataSourceConstraint).get(availability1).getMetricNames() == [metric1] as Set
+        metricUnionAvailability.constructSubConstraint(physicalDataSourceConstraint).get(availability2).getMetricNames() == [metric2] as Set
+    }


The variable name for the ignored column in the mocks is confusable with the ignored request column. Change the name to something distinctive like 'unrequested' on the mock.

This test reveals another, existing problem. We should be defensive that the 'ignored2' gets handled correctly in getAvailableIntervals().

Probably a test before streaming that PhysicalDataSourceConstraint.allColumnPhysicalNames is a subset of metricNames.
To align with ConcreteAvailability it should return empty SIL.

(And a test for that case)

…lity data

cdeszaq · 2017-04-14T20:02:17Z

...core/src/main/java/com/yahoo/bard/webservice/table/availability/MetricUnionAvailability.java

+    public SimplifiedIntervalList getAvailableIntervals(PhysicalDataSourceConstraint constraint) {
+
+        // If there are columns requested that are not configured on this table
+        if (constraint.getAllColumnPhysicalNames().size() != constraint.getAllColumnNames().size()) {


This will likely always be true, due to the defaulting behavior of how mapping from logicalToPhysicalName works. We probably need to look at the union of the columns in the subconstraints to see if any of the requested columns are not present in the subconstraints.

… data source constraint

cdeszaq · 2017-04-17T15:23:53Z

fili-core/src/main/java/com/yahoo/bard/webservice/table/BasePhysicalTable.java

+        if (!constraint.getAllColumnNames().stream().allMatch(tableColumnNames::contains)) {
+            String message = String.format(
+                    "Received invalid request requesting for columns: %s that is not available in this table: %s",
+                    invalidColumnNames.stream().collect(Collectors.joining(",")),


Rather than computing invalidColumnNames every time, let's replace the formatting stream here with the computation for the invalid names:

Set<String> constraintColumnNames = constraint.getAllColumnNames(); // ... constraintColumnNames.stream().filter(name -> !tableColumnNames.contains(name)).collect(Collectors.joining(","))

cdeszaq · 2017-04-17T15:25:45Z

fili-core/src/test/groovy/com/yahoo/bard/webservice/table/ConcretePhysicalTableSpec.groovy

-        new Column("MissingName")   | [] as Set
+    }
+
+    @Unroll


No need for @Unroll here, since there's no where block and no templated test name.

cdeszaq · 2017-04-17T15:27:29Z

Just those few trivial things, and this will merge.

cdeszaq requested changes Apr 4, 2017

View reviewed changes

garyluoex added the WIP label Apr 5, 2017

garyluoex force-pushed the FixPartialData branch 4 times, most recently from 97bfd0d to e2a36f1 Compare April 5, 2017 16:29

garyluoex added NEED 2 REVIEWS REVIEWABLE and removed WIP labels Apr 5, 2017

michael-mclawhorn requested changes Apr 5, 2017

View reviewed changes

garyluoex force-pushed the FixPartialData branch from e2a36f1 to 8b6212e Compare April 7, 2017 19:18

michael-mclawhorn self-assigned this Apr 11, 2017

garyluoex assigned cdeszaq Apr 11, 2017

michael-mclawhorn requested changes Apr 12, 2017

View reviewed changes

michael-mclawhorn requested a review from QubitPi April 12, 2017 16:40

QubitPi suggested changes Apr 12, 2017

View reviewed changes

cdeszaq requested changes Apr 12, 2017

View reviewed changes

garyluoex force-pushed the FixPartialData branch 2 times, most recently from 52ece84 to da27321 Compare April 13, 2017 16:03

michael-mclawhorn approved these changes Apr 13, 2017

View reviewed changes

cdeszaq mentioned this pull request Apr 13, 2017

Support Filtering Segment Availability from Availability Service #77

Closed

cdeszaq requested changes Apr 13, 2017

View reviewed changes

garyluoex force-pushed the FixPartialData branch from da27321 to f038837 Compare April 13, 2017 20:26

garyluoex added WIP and removed REVIEWABLE labels Apr 13, 2017

garyluoex force-pushed the FixPartialData branch from f038837 to f5e3d97 Compare April 13, 2017 21:44

cdeszaq requested changes Apr 13, 2017

View reviewed changes

garyluoex added REVIEWABLE and removed WIP labels Apr 14, 2017

garyluoex force-pushed the FixPartialData branch from 143b2f7 to 5e684e6 Compare April 14, 2017 15:53

cdeszaq reviewed Apr 14, 2017

View reviewed changes

cdeszaq approved these changes Apr 14, 2017

View reviewed changes

cdeszaq added MERGEABLE NEED CHANGES and removed NEED 2 REVIEWS labels Apr 14, 2017

michael-mclawhorn requested changes Apr 14, 2017

View reviewed changes

garyluoex added 4 commits April 14, 2017 13:23

Fix using logiccal name instead of phsyical name to retireve availabi…

d8d2659

…lity data

Modified according to mike's comments

dbe991c

Modified according to three person's coments

91abe7f

Rebased onto master, still need to look at tests

d094ec8

QubitPi approved these changes Apr 14, 2017

View reviewed changes

garyluoex added 2 commits April 14, 2017 13:26

Updated tests and modified according to rick's comments

ee87d8a

Modified according to mike and rick's latest comments

52598ac

garyluoex force-pushed the FixPartialData branch from 5e684e6 to 52598ac Compare April 14, 2017 19:36

garyluoex removed the NEED CHANGES label Apr 14, 2017

cdeszaq reviewed Apr 14, 2017

View reviewed changes

Latest update to rick's concern regarding removing filter in physical…

8b0c5e6

… data source constraint

cdeszaq reviewed Apr 17, 2017

View reviewed changes

garyluoex removed the MERGEABLE label Apr 17, 2017

Modified according to rick's comment and a bug fix

a451011

garyluoex added the MERGEABLE label Apr 17, 2017

cdeszaq merged commit c6bbe69 into master Apr 17, 2017

garyluoex deleted the FixPartialData branch April 17, 2017 17:16

garyluoex mentioned this pull request Apr 17, 2017

Insufficient tests for MetricUnionAvailability's constructSubConstraints method and related calls #238

Closed

		@@ -49,15 +50,14 @@ class PermissiveAvailabilitySpec extends Specification {

		@@ -79,12 +82,21 @@ public DateTime getTableAlignment() {

		@Override

Fix to use physical name instead of logical name to retrieve available interval #226

Fix to use physical name instead of logical name to retrieve available interval #226

Conversation

garyluoex commented Apr 4, 2017 • edited Loading

cdeszaq left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

garyluoex Apr 5, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michael-mclawhorn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michael-mclawhorn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdeszaq left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

michael-mclawhorn left a comment

Choose a reason for hiding this comment

cdeszaq left a comment • edited Loading

Choose a reason for hiding this comment

cdeszaq left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdeszaq left a comment

Choose a reason for hiding this comment

michael-mclawhorn left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdeszaq Apr 17, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cdeszaq commented Apr 17, 2017

garyluoex commented Apr 4, 2017 •

edited

Loading

garyluoex Apr 5, 2017 •

edited

Loading

cdeszaq left a comment •

edited

Loading

cdeszaq Apr 17, 2017 •

edited

Loading