- iOS/Android DBI Strategy - Keys, Takeaways
- Focus on Mobile Only = SQLite
- Kotlinish DBI
- JDBCish DBI
- Java JPA and other Frameworks
- Advanced Local Storage, File Systems, NoSQL
iOS/Android DBI Strategy - Keys, Takeaways
IOS-Android DBI libraries STR - mostly SQLite - pre-kotlin
STR Kotlinish - Multplat SQLite only ios/andr
Resources BE DBI Other Src, Sort
- BE oriented vs IOS/Android "pointer to secure file/perms"
Focus on Mobile Only = SQLite
- SQLite/SQLDelight Kotlin Multiplatform - YouTube
- [cashapp/sqldelight: SQLDelight - Generates typesafe Kotlin APIs from SQL
- Have a project now using multiplatform on iOS and Android with local storage using sqldelight. It’s great for that.
- I highly enjoy using SQL Delight. It also has the advantage of multiplatform support, if that's something you're interested in.
- For a long time I was using jooq. But moved on do to hard time mapping join records, and being tied to jdbc. I've been using jasync and getting much better performance.
Hand Crafted Android SQLite libs
r Kotlin SQLite DBI - Hand built
Exposed was but I want more - a typesafe builder. Something that builds types from the db and gives near sql syntax. https://animusdesign.gitlab.io/kotlin-frm/#/
Exposed Kotlin SQL Framework
- boilerplate is a bit much - Doesn't make too much sense and data access is generally through weakly typed runtime maps, unless you write twice the boilerplate to get it in POJO
- to add just one column, you have to add the same field in many places: 1. The table schema object 2. The data class 3. The mapper for object -> class 4. Mapper for class -> object
- And add another one for any read/update you want to do in the Service class to actually access your model SO Really high scope for human error and this would be a nightmare to maintain.
- jOOQ was a much easier replacement for legacy plain SQL & JDBC than some ORM would be .. but also added it to some older projects that primarily used Hibernate, in cases where I needed extra control over my queries, and it works great, the two mix quite happily.
https://www.jooq.org/ - WHY? Query composition, of course. No pasting of SQL strings - jOOQ can be written extremely modular and composed in code. Fully type & injection safe. - well designed library. It let's you write what is basically normal sql but in a completely typesafe way. The maintainer is also wonderful. He answers questions all the time and is very responsive to bugs and feature requests. - +HikariCP just helps manage the connection pool - + Flyway helps you manage your db schema and migrations. You can use them independently of jooq, but they compliment it nicely.
- Super easy and straight forward. If you're like me in that you dislike ORMs and are comfortable writing SQL, but want to abstract away the tedious things like mapping to/from POJO/POKOs jdbi is best in class.
I've been using the fluent interface with the actual SQL statements in multi-line strings. I find it easier to debug than the object interface and there's not not too much boilerplate
spring-data-jdbc is really good. https://spring.io/projects/spring-data-jdbc
Java JPA and other Frameworks
ebean orm - https://ebean.io It uses JPA mappings, it's aware of Kotlin non-nullable types, type safe queries (Kotlin and Java), avoids N+1, partial object support, db migration generation and running, testing via docker container support, sql 2011 history support etc.
Advanced Local Storage, File Systems, NoSQL
Local Storage - file systems
- adibfara/Lives: Lives - Android LiveData Extensions for Kotlin and Java
- netguru/Kissme: Kissme: Kotlin Secure Storage Multiplatform