newEntries[outI++] = entries[inI];
        }
      }
      return newEntries;
    }
  }

  /**
   * Returns an immutable map containing the same entries as {@code map}. The returned map iterates
   * over entries in the same order as the {@code entrySet} of the original map. If {@code map}
   * somehow contains entries with duplicate keys (for example, if it is a {@code SortedMap} whose

    }

    // Because we happen to use the same formula. If that changes, just don't override this.
    @Override
    public int hashCode() {
      return parent.hashCode();
    }

    @Override
    public String toString() {
      return parent.toString();
    }
  }

  /**
   * Returns {@code true} if {@code object} is an {@code ImmutableLongArray} containing the same
   * values as this one, in the same order.

    }

    // Because we happen to use the same formula. If that changes, just don't override this.
    @Override
    public int hashCode() {
      return parent.hashCode();
    }

    @Override
    public String toString() {
      return parent.toString();
    }
  }

  /**
   * Returns {@code true} if {@code object} is an {@code ImmutableIntArray} containing the same
   * values as this one, in the same order.

 * need for a distinct {@code ImmutableBiMultimap} type.
 *
 * <p><a id="iteration"></a>
 *
 * <p><b>Key-grouped iteration.</b> All view collections follow the same iteration order. In all
 * current implementations, the iteration order always keeps multiple entries with the same key
 * together. Any creation method that would customarily respect insertion order (such as {@link

    mergeAdjacentDeltaMappedRanges(sectionList)
  }

  return result.toMap()
}

/**
 * Modifies [ranges] to combine any adjacent [MappedRange.InlineDelta] of same size to single entry.
 * @returns same instance of [ranges] for convenience
 */
internal fun mergeAdjacentDeltaMappedRanges(ranges: MutableList<MappedRange>): MutableList<MappedRange> {
  var i = 0
  while (i < ranges.size) {

(A SQL separator is semicolon ";")

take-finally-*.sql:
SQL statements for check loaded data (or DDL after data loading)
You should write your own SQL statements in this file.
(basically same specifications as replace-schema.sql)

The "data" directory is for data loading like this:
/- - - - - - - - - - - - - - - - - - - -
playsql
  |-data
     |-common
     |  |-xls
     |     |-10-master.xls

   * exactly one entry for each distinct element in the multiset (thus it always has the same size
   * as the {@link #elementSet}). The order of the elements in the element set is unspecified.
   *
   * <p>The entry set is backed by the same data as the multiset, so any change to either is
   * immediately reflected in the other. However, multiset changes may or may not be reflected in

 * with the range (if any) that contains a specified key.
 *
 * <p>In contrast to {@link RangeSet}, no "coalescing" is done of {@linkplain
 * Range#isConnected(Range) connected} ranges, even if they are mapped to the same value.
 *
 * @author Louis Wasserman
 * @since 14.0
 */
@SuppressWarnings("rawtypes") // https://github.com/google/guava/issues/989
@DoNotMock("Use ImmutableRangeMap or TreeRangeMap")
@GwtIncompatible

   */
  public final FluentIterable<E> skip(int numberToSkip) {
    return from(Iterables.skip(getDelegate(), numberToSkip));
  }

  /**
   * Creates a fluent iterable with the first {@code size} elements of this fluent iterable. If this
   * fluent iterable does not contain that many elements, the returned fluent iterable will have the

```sh
kubectl get secrets
```

You should see a secret named `tls-ssl-minio`.

## 3. Update deployment yaml file

Whether you are planning to use Kubernetes StatefulSet or Kubernetes Deployment, the steps remain the same.

If you're using certificates provided by a CA, add the below section in your yaml file under `spec.volumes[]`

```yaml
    volumes:
      - name: secret-volume
        secret:
          secretName: tls-ssl-minio