Support for compound keys #3
Labels
Milestone
Comments
|
Yes, compound keys would be very nice to have, not sure when this happens though. At the very least we need another refactoring of internal structures (#57). |
|
Blocked by #54, but we're a step closer. |
This was referenced Apr 27, 2020
Merged
|
Now tracked in https://github.com/krlmlr/dm/projects/2. |
This was referenced Apr 26, 2021
krlmlr
added a commit
that referenced
this issue
Apr 28, 2021
- `dm_add_pk()` and `dm_add_fk()` support compound keys via the `c()` notation, e.g. `dm_add_pk(dm, table, c(col1, col2))`. `dm_nycflights13()` returns a data model with compound keys by default. Use `compound = FALSE` to return the data model from dm 0.1.13 or earlier (#3). - `dm_get_all_fks()` includes `parent_pk_cols` column that describes the primary key columns of the parent table (#335). - `dm_examine_constraints()` and other check functions count the number of rows that violate constraints for primary and foreign keys (#335). - `copy_dm_to(set_key_constraints = FALSE)` downgrades unique indexess to regular indexes (#335). - `rows_truncate()` implemented for data frames (#335). - `dm_enum_fk_candidates()` enumerates column in the order they apper in the table (#335).
|
Support will be added in dm 0.2.0, planning to send it to CRAN this week. |
krlmlr
added a commit
that referenced
this issue
May 4, 2021
dm 0.2.0 - Deprecate `dm_get_src()` `tbl.dm()`, `src_tbls.dm()`, `copy_to.dm()`. These functions have better alternatives and use the notion of a "data source" which is being phased out of dplyr (#527). - `*_pk()` and `*_fk()` functions gain an ellipsis argument that comes before `check`, `force` and `rm_referencing_fks` arguments (#520). - `dm_add_pk()` and `dm_add_fk()` support compound keys via the `c()` notation, e.g. `dm_add_pk(dm, table, c(col1, col2))`. `dm_nycflights13()` returns a data model with compound keys by default. Use `compound = FALSE` to return the data model from dm v0.1.13 or earlier (#3). - `dm_get_all_fks()` includes `parent_pk_cols` column that describes the primary key columns of the parent table (#335). - `dm_from_src()` supports the `schema` argument also for MariaDB and MySQL databases (#516). - dm objects now inherit from `"dm_v1"` in addition to `"dm"`, to allow backward-compatible changes of the internal format (#521). - Use hack to create compound primary keys on the database (#522). - `dm_examine_constraints()` and other check functions count the number of rows that violate constraints for primary and foreign keys (#335). - `copy_dm_to(set_key_constraints = FALSE)` downgrades unique indexes to regular indexes (#335). - `rows_truncate()` implemented for data frames (#335). - `dm_enum_fk_candidates()` enumerates column in the order they apper in the table (#335).
|
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. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Are there any plans/thoughts on supporting compound keys? I frequently have a table where the primary key is a combination of fields. It looks like putting a PK constraint on something like that in
dmrequires creating a new single column that is a mutation of the two non-unique components.Thanks for the package!
The text was updated successfully, but these errors were encountered: