By default filter out deleted entries with get_df()? about sidora.core HOT 9 CLOSED

Right - that's not a good solution. I'll change it.

from sidora.core.

this_tab <- get_con(tab, con) %>% tibble::as_tibble() %>% dplyr::filter(deleted == "false")

Could also consider defining column types on load to speed up filtering (i.e. not string matching but rather boolean selection)?

from sidora.core.

I implemented this for now. Please test.

Could also consider defining column types on load to speed up filtering (i.e. not string matching but rather boolean selection)?

I think we can not do that on the connection level, but only downstream, but please correct me if I'm wrong.

I suggest to implement a function fix_types that applies all these transformations (Creatiion_Date -> as.Date, Deleted -> as.logical, etc.) to local/downloaded tables.

from sidora.core.

I implemented this for now. Please test.

Works for e

Could also consider defining column types on load to speed up filtering (i.e. not string matching but rather boolean selection)?

I think we can not do that on the connection level, but only downstream, but please correct me if I'm wrong.

I suggest to implement a function fix_types that applies all these transformations (Creatiion_Date -> as.Date, Deleted -> as.logical, etc.) to local/downloaded tables.

Sounds good. Shall I make a list for you for each column accordingly for each table? Is there a good place to put 'data' objects (so to say, rather than functions), in a package?

from sidora.core.

I don't know whether it makes sense to store this as a data object. I hope the column transformations are consistent across all tables? I mean: If the table has a column Creation_Date then it should be a date object in all cases? Then we could easily cover this in R code, I guess.

R Packages can store data. The usual way to do this is to add a directory data-raw that contains raw .csv tables and a prep script that reads the raw data and calls usethis::use_data for each object. You can also write function documentation for data object. Don't forget to add the data-raw directory to the .Rbuildignore

from sidora.core.

Sorry, yes, I didn't mean data per se. I meant an internal vector or list. Or would that just go straight into a function, like you did with the tab vetor in get_con?

Actually, I'll make a PR in a few minutes with the lists showing you what I mean.

from sidora.core.

For the moment I would just put it into the function. Later we can outsource it to data objects. Our package has a very specific purpose, so I don't think we have to care too much about abstraction.

from sidora.core.

Hm ok. Because for example you're already copying your tab vector across multiple functions. Wondering what would happen if a new TAB was added.

from sidora.core.

Done

from sidora.core.