nrow() in duckspatial_df

[rafapereirabr]

It would be nice to count the number of rows in a duckspatial_df by simply using base R nrow(). Currently it returns NA. Counting the number of columns with ncol() works fine.

library(duckspatial)

# Load polygon data
countries_ddbs <- ddbs_open_dataset(
  system.file("spatial/countries.geojson", package = "duckspatial")
  )

ncol(countries_ddbs)
#> 8

nrow(countries_ddbs)
#> NA

dim(countries_ddbs)
#> NA  8

[e-kotov]

Well we can surely do it, however.

Adding nrow (and essentially dim too, as in implementation they would need to be both for technical reasons) to duckspatial means we are stepping slightly away from dbplyr's strict laziness. While dbplyr always returns NA for row counts to save time by not querying the database, sf users expect to see how many features they have. duckplyr tries a fancy ALTREP approach (which I tired back in December for duckspatial and it was hard to implemtn with geom columns, at least back then) but still defaults to NA during printing to keep things fast. I decided to just run a quick count query. My benchmarks showed it takes around 1.5 milliseconds even on a million rows, so users get that familiar sf experience without a noticeable slow down. But he question is, do we want to deviate from dbplyr and duckplyr in pursuit to be more user friendly but potentially hit problems later on, as we essentially are building on top of dbplyr heavily. I don't know what can happen, but it is a good moment to pause and think about it.

For tally and count from dplyr, we have to pick between being fast like dbplyr or map-ready like sf. The sf package automatically st_unions geometry when you count or tally, which is handy but super slow on large datasets. It does this to stick with concept of 'geometry is sticky, so don't drop it under any circumstances unless explicitly told to sf_drop_geomewtry '. So in duckspatial we probably do not want to do st_union for count/tally as this is super wasteful for large data sets... But then again, this will deviate from sf. The question is again, how much do we want to deviate form behaviour that will differ from sf.

My opinion, is that we can deviate from established practices to optimize for speed and convenience, so be opinionated how the package behaves.