GoToSocial WASM-based SQLite driver and BSD

8

GoToSocial WASM-based SQLite driver and BSD freebsd netbsd tumfatig.net
via jaypatelani 4 months ago | caches
Archive.org Archive.today Ghostarchive
| 6 comments

6

1. 3
  mariusor 4 months ago
  Meanwhile on my own ActivityPub services the way to use different sqlite implementations is just:
  
  -//go:build cgo +//go:build !cgo package sqlite import ( "database/sql" - _ "github.com/mattn/go-sqlite3" + _ "modernc.org/sqlite" ) var sqlOpen = func(dataSourceName string) (*sql.DB, error) { - return sql.Open("sqlite3", dataSourceName) + return sql.Open("sqlite", dataSourceName) }
2. 2
  
  oz 4 months ago
  
  I’m sorry if that is off-topic, but what does GtS gain from having a WASM-based sqlite driver?
  1. 2
    
    zimpenfish 4 months ago
    
    Not needing a C compiler on your build machine + not having the (infrequent, to be fair) hideously long build times you get when using mattn/go-sqlite3.
    1. 2
      
      oz 4 months ago
      
      Thanks, I think you’re right and that cgo is the main reason to skip mattn/go-sqlite3 in some contexts. :)
      
      On the other hand, modernc.org/sqlite is advertised as a “cgo-free” sqlite driver, so if “no-cgo” was the goal, maybe GtS could have used this instead of mattn’s driver. I would understand the need for WASM if it improved performance over the others, but this article seems to contradict that idea a bit (at least regarding memory, these numbers look very weird).
      
      So I’m still confused, sorry. Maybe I need more caffeine. :)
      1. 3
        
        winter 4 months ago
        
        My understanding was that GtS does use modernc’s sqlite, and this is why it’s broken on OpenBSD (for now?).
        
        1
        
        zimpenfish 2 months ago
        
        Checked and it looks like there’s a build-time choice between modernc.org/sqlite (transcoded Go) and github.com/ncruces/go-sqlite3 (wrapped WASM)