7 ms·

Thank you (GRDB author here). It is not mentioned in the README of the repository, but SQLiteData wraps GRDB to access the database and get notified of databas

by groue 1y ago

Thank you (GRDB author here). It is not mentioned in the README of the repository, but SQLiteData wraps GRDB to access the database and get notified of database changes (the meat and butter). GRDB is by itself a solid "toolkit for SQLite databases, with a focus on application development", with both high levels APIs for everyday coding, and expert SQLite features for the demanding developers. Many apps rely on GRDB alone.

jparishy 1y ago
Used GRDB many times in a previous life, thank you very much for your work
mikeocool 1y ago
Oh hi -- Thanks for your work! Just finished replacing SwiftData in an app with GRDB and it was a pleasure to use. After struggling with some issues in SwiftData, GRDB really hits the nail on the head in terms of providing a solid dev experience for the common cases, but allowing you to drop into the more advanced features when you need them.
- groue 1y ago
  You're welcome :)
mbw234 1y ago
Sorry about that, just opened a PR to update the readme and docs landing page! Previously it was very clear that GRDB was being used under the hood, but now we will say it explicitly.
dgllghr 1y ago
Thank you for GRDB! I am using it in a project now and it’s been great. About the benchmarks in this repo though, how can SQLiteData be faster if it uses GRDB under the hood? Are they doing something inefficient or are they bypassing GRDB in some way?
- wahnfrieden 1y ago
  GRDB appears to encourage Codable which is very slow. It does not require it though and there are some alternatives, some of which are also slow. ("Slow" can still mean "fast enough", depending on the user.) SQLiteData uses this library which uses Swift macros to generate performant interfaces to schema statically at build time: https://github.com/pointfreeco/swift-structured-queries https://github.com/pointfreeco/swift-structured-queries The alternative I've seen for doing this with GRDB seemed more cumbersome and lacks community adoption: https://github.com/Jasperav/GRDB-ORM https://github.com/Jasperav/GRDB-ORM You must define schema and queries in an unusual external file that a Rust tool transforms for you. There is also this library which does not use GRDB but takes a similar approach to SQLiteData though you have to run a program that generates the bindings outside of your normal build: https://lighter-swift.github.io/documentation/lighter/performance/ https://lighter-swift.github.io/documentation/lighter/perfor...
  - dgllghr 1y ago
    Now I understand. Thanks!
  - groue 1y ago
    Yes. GRDB encourages Codable because the user can profit from the code generated by the compiler, and this implies that database values are accessed by column name, on top of the Codable runtime, and those layers have a high cost. When necessary it is possible to access database values by position, and in this case GRDB achieves speed of light (performance nearly identical as raw SQLite).
    - wahnfrieden 1y ago
      From my understanding this is a sample of the database values by position approach: https://github.com/Lighter-swift/PerformanceTestSuite/blob/main/Sources/PerformanceTests/GRDBTests.swift https://github.com/Lighter-swift/PerformanceTestSuite/blob/m... That approach benchmarks at 2.2x the duration of StructuredQueries (45% as fast): https://github.com/Lighter-swift/PerformanceTestSuite/blob/8bfc38b853d47da86991451cd7e407a9552a74f3/Sources/PerformanceTests/StructuredQueriesTests.swift https://github.com/Lighter-swift/PerformanceTestSuite/blob/8... 18.819s vs 8.511s So it appears that there is lightning-fast and lighting-faster. Of course aside from comparing the dev ergonomics (138 vs 33 lines for the respective benchmarks), either may be fast enough depending on the use case. BTW I did also see some discussion in swift-evolution about a future replacement for Codable but haven't tracked its progress. I hope they do because Codable is very convenient but tragically slow.
yAak 1y ago
GRDB is an invaluable tool to me and, IMO, to the Swift community — thank you for open-sourcing your countless hours of work and expertise!!

by groue 1y ago

jparishy 1y ago

Used GRDB many times in a previous life, thank you very much for your work

mikeocool 1y ago

Oh hi -- Thanks for your work! Just finished replacing SwiftData in an app with GRDB and it was a pleasure to use. After struggling with some issues in SwiftData, GRDB really hits the nail on the head in terms of providing a solid dev experience for the common cases, but allowing you to drop into the more advanced features when you need them.

groue 1y ago
You're welcome :)

mbw234 1y ago

Sorry about that, just opened a PR to update the readme and docs landing page! Previously it was very clear that GRDB was being used under the hood, but now we will say it explicitly.

dgllghr 1y ago

Thank you for GRDB! I am using it in a project now and it’s been great. About the benchmarks in this repo though, how can SQLiteData be faster if it uses GRDB under the hood? Are they doing something inefficient or are they bypassing GRDB in some way?

wahnfrieden 1y ago
GRDB appears to encourage Codable which is very slow. It does not require it though and there are some alternatives, some of which are also slow. ("Slow" can still mean "fast enough", depending on the user.) SQLiteData uses this library which uses Swift macros to generate performant interfaces to schema statically at build time: https://github.com/pointfreeco/swift-structured-queries https://github.com/pointfreeco/swift-structured-queries The alternative I've seen for doing this with GRDB seemed more cumbersome and lacks community adoption: https://github.com/Jasperav/GRDB-ORM https://github.com/Jasperav/GRDB-ORM You must define schema and queries in an unusual external file that a Rust tool transforms for you. There is also this library which does not use GRDB but takes a similar approach to SQLiteData though you have to run a program that generates the bindings outside of your normal build: https://lighter-swift.github.io/documentation/lighter/performance/ https://lighter-swift.github.io/documentation/lighter/perfor...
- dgllghr 1y ago
  Now I understand. Thanks!
- groue 1y ago
  Yes. GRDB encourages Codable because the user can profit from the code generated by the compiler, and this implies that database values are accessed by column name, on top of the Codable runtime, and those layers have a high cost. When necessary it is possible to access database values by position, and in this case GRDB achieves speed of light (performance nearly identical as raw SQLite).
  - wahnfrieden 1y ago
    From my understanding this is a sample of the database values by position approach: https://github.com/Lighter-swift/PerformanceTestSuite/blob/main/Sources/PerformanceTests/GRDBTests.swift https://github.com/Lighter-swift/PerformanceTestSuite/blob/m... That approach benchmarks at 2.2x the duration of StructuredQueries (45% as fast): https://github.com/Lighter-swift/PerformanceTestSuite/blob/8bfc38b853d47da86991451cd7e407a9552a74f3/Sources/PerformanceTests/StructuredQueriesTests.swift https://github.com/Lighter-swift/PerformanceTestSuite/blob/8... 18.819s vs 8.511s So it appears that there is lightning-fast and lighting-faster. Of course aside from comparing the dev ergonomics (138 vs 33 lines for the respective benchmarks), either may be fast enough depending on the use case. BTW I did also see some discussion in swift-evolution about a future replacement for Codable but haven't tracked its progress. I hope they do because Codable is very convenient but tragically slow.

yAak 1y ago

GRDB is an invaluable tool to me and, IMO, to the Swift community — thank you for open-sourcing your countless hours of work and expertise!!