feat(glue): add L2 resources for Database and Table

[sam-goodwin]

This change adds L2 resources for Database and Table.

const database = new glue.Database(stack, 'MyDatabase', {
  databaseName: 'my_database'
});

new glue.Table(stack, 'MyTable', {
  database,
  tableName: 'my_table',
  columns: [{
    name: 'col1',
    type: glue.Schema.string
  }],
  partitionKeys: [{
    name: 'year',
    type: glue.Schema.smallint
  }, {
    name: 'month',
    type: glue.Schema.smallint
  }],
  storageType: glue.StorageType.Json
});

Schemas are defined as an array of Column, each of which have a name and a Type:

Types

A table's schema is a collection of columns, each of which have a name and a type. Types are recursive structures, consisting of primitive and complex types:

Primitive

Numeric:

• bigint
• float
• integer
• smallint
• tinyint

Date and Time:

• date
• timestamp

String Types:

• string
• decimal
• char
• varchar

Misc:

• boolean
• binary

Complex

• array - array of some other type.
• map - map of some primitive key type to any value type.
• struct - nested structure containing individually named and typed columns.

---

Pull Request Checklist

• Testing
  • Unit test added (prefer not to modify an existing test, otherwise, it's probably a breaking change)
  • CLI change?: coordinate update of integration tests with team
  • cdk-init template change?: coordinated update of integration tests with team
• Docs
  • jsdocs: All public APIs documented
  • README: README and/or documentation topic updated
• Title and Description
  • Change type: title prefixed with fix, feat will appear in changelog
  • Title: use lower-case and doesn't end with a period
  • Breaking?: last paragraph: "BREAKING CHANGE: <describe what changed + link for details>"
  • Issues: Indicate issues fixed via: "Fixes #xxx" or "Closes #xxx"
• Sensitive Modules (requires 2 PR approvers)
  • IAM Policy Document (in @aws-cdk/aws-iam)
  • EC2 Security Groups and ACLs (in @aws-cdk/aws-ec2)
  • Grant APIs (only if not based on official documentation with a reference)

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license.

[eladb]

beautiful

[eladb]

I am wondering, if name is unique, why not use a hash?

[sam-goodwin]

There are two semantics we want to model as strictly as we can: column uniqueness and ordering.

• A hash models uniqueness well, but it does not model ordering. In node.js, the order of variables is the order in which they are added to the object, but that is not the case for other languages like java, where a developer would have to know to use a LinkedHashMap.
• An array explicitly and intuitively defines the ordering in all languages, but it doesn't model column uniqueness.

I chose to statically model the ordering property with an array and check the uniqueness at runtime because then, at least the experience is consistent for all consumers. Using a hash might create confusion for consumers - they would not receive an error, the layout of their columns could just change arbitrarily.

[eladb]

Default to JSON?

[sam-goodwin]

I think it's best to ask customers to be explicit about their data format. Front-load the important questions: schema, file format, location and security.

[eladb]

Enum names should be consistent with BucketEncryption

[sam-goodwin]

I would argue the other way around - the enum values are consistent with the S3, Athena, Glue and EMR documentation. What would I name CSE-KMS if I were copying BucketEncryption?

[eladb]

Fair enough, but I think we have a problem with ALL_CAPS when converting those member names to other languages. Can we find names that are PascalCase?

[eladb]

Proposed names that pass the jsii naming bar:

• Unencrypted
• SSE_KMS => Kms
• SSE_KMS_MANAGED => KmsManaged
• SSE-S3 => S3Managed
• CSE_KMS => ClientKms

[sam-goodwin]

Your way distinguishes CSE with the prefix Client and implies SSE for the others. It's efficient. I think I'd prefer ClientSideKms over ClientKms, though.

[eladb]

Sounds good to me.

I am okay with ServerSideXxx as well, but then we'll have to also change it in other places ;-) and I favor consistency at this point.