Understand limitations of current implementation

[krlmlr]

when compound keys exist in the data model.

On top of #335, or as part of it.

• Implement compound = FALSE argument to dm_nycflights13().
• Walk through all functions in https://krlmlr.github.io/dm/dev/reference/. For each function:
  • find an example that uses dm_nycflights13(compound = TRUE)
  • add a verify_output() test to the bottom of the relevant tests/testthat/test-*.R file
    • naked, do not wrap into test_that("...", {})
  • do not attempt to fix

[krlmlr]

Perhaps we need more data models with compound keys in addition. These need to wait until later, we can add tests for everything that can be tested with nycflights13 and FIXMEs for what needs other data models.

[TSchiefer]

Currently a limitation is, that dm_nycflights13(compound = TRUE) does not work on PG.
Error is:

Error: Failed to fetch row: ERROR:  column "(origin, time_hour)" does not exist

Should I ignore this for now or investigate/try solving?

[TSchiefer]

Reason is, that build_copy_data() interprets the key columns (origin, time_hour) as one column and tries to establish unique indices for it.

Should the keys-class maybe be a list that allows entries with length > 1?

And do unique indices work for a compound key at all on a DB?

[krlmlr]

Let's not attempt to fix for now.

[krlmlr]

When we see the big picture, it becomes clearer where to focus efforts first.

[krlmlr]

Done in #436. Need to create issues for next steps.

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.