SQLDelight の データベースバージョン

「分かれば簡単だけど、分かるまで難しい」

そんなこと多いですよね。

なにを悩んでいたのか。というやつ。

SQLDelight は、1.0 となり、今現在、ドキュメントやリファレンスが少なくてはまります。

おおまかに「しくみ」を捉えてからやってみること大事です。

 

1.テーブル作成

テーブルを作成したい場合。SQLで、


CREATE TABLE player (
  id INTEGER NOT NULL PRIMARY KEY AUTOINCREMENT,
  number INTEGER NOT NULL,
  name TEXT NOT NULL,
  time TEXT DEFAULT (strftime('%s', 'now')),
  UNIQUE (number, name)
);

のようなものを書きますよね。

これは、Player.sq というファイルに書いて、所定の位置に置きます。

この位置はデフォルトでは、パッケージ名 com.example.testdelight の場合、


/app/src/main/sqldelight/com/example/testdelight/Player.sq

となります。

 

2.クエリー作成

プログラムコード上で利用したい「メソッド名」と、それに対するSQLを箇条書きにします。


selectAll:
SELECT *
FROM player;

insert:
INSERT INTO player(number, name)
VALUES (?, ?);

changes:
SELECT changes();

count:
SELECT COUNT(id)
FROM player;

これも、前述の Player.sq ファイルに追記します。

これで、テーブル周りの設定は終わりです。

 

3.スキーマのバージョン

ここが少し分かりづらかったのですが、

「201901281」を新バージョンにしたい場合、

「1を引いたもの」をファイル名として、

「201901280.sqm」

として置きます。

今回は、テーブル定義の変更はないので、中身なしの空ファイルです。

少し不思議な感じがしますが、書き出してみると分かってきます。

なお、このファイルを設定しなければ、適用されるバージョンは「1」となります。

 

4.ビルドして書き出す

ここでビルドすると、以下のようなファイルが書き出されます。

それぞれ以下のコードとなっています。

これらを使って、コードを書いていきます。

 

まとめ

既存の .db ファイルに対して、バージョン更新を行いたい場合のキモとなるのは、書き出される Database ファイル。


object Schema : SqlDriver.Schema {

     override val version: Int
         get() = 201901281 // 201801280 + 1

     // ...

     override fun migrate(
         driver: SqlDriver,
         oldVersion: Int,
         newVersion: Int
     ) {
         if (oldVersion <= 201901280 && newVersion > 201901280) { // same .sqm file name

           // from 201801280.sqm contents
           // ...

         }
     }
 }

.sqm のファイル名の数字が、

「新バージョンの数字」
「適用される既存.db のバージョンの数字」

を決める。

SQLDelight 1.0 使い方 #1
SQLDelight 1.0 使い方 #2
SQLiteのユーザバージョンを利用する - Basic
Pragma statements supported by SQLite




新「元号」の西暦へ変換方法と「Build.VERSON_CODES」

今回もまた、和暦と西暦の変換の方法とか。

昭和:元号に25を足すと西暦。
平成:元号から12を引くと西暦。
?? : 元号に18を足すと西暦。

面倒ですね。

一方、Android OS (API) バージョンの呼び方。


19 KITKAT                 4.4 - 4.4.4   KitKat
21 LOLLIPOP               5             Lollipop
22 LOLLIPOP_MR1           5.1           Lollipop
23 M                      6             Marshmallow
24 N                      7             Nougat
25 N_MR1                  7.1           Nougat
26 O                      8.0           Oreo
27 O_MR1                  8.1           Oreo
28 P	                  9.0           Pie

Android バージョンやコードネームなどからのシェアの一覧取得


同じ意味なのに別の呼称があることは、少し考えての変換が必要になる。

いらなくね? 元号とかコードネームとか。

まあ、コードネームを付けることで話題として取り上げやすくはなるわな。

キャバ嬢の「平成生まれ」をうれしがってた時もあったけどなあ。

Android OS バージョン確認方法 (platform versions)

The Unicode Blog: New Japanese Era


本物「Jake Wharthon」さん、偽物「Jake Whaarton」になりすます

jitpack で配布しているライブラリに不必要な怪しい通信処理を入れて

Bintray -> jcenter() 経由で同じアーティファクトidで配布してる「Jake Whaarton」さん。

これは、神と呼ばれるJakeWarthonさんの偽物です。

Jake Wharthon → 本物
Jake Whaarton → 偽物

少し話題になってましたね。

A Confusing Dependency

A Confusing Dependency : androiddev

すると、本物JakeさんのTwitterが!!

Jake Whaarton(@JakeWharton)さん | Twitter

なりすましてます、本物が偽物に。

この話を、解説しています。

アーティファクトの整合性の話は別にして、jcenter() を常に最後に置くだけでなく、mavenCentral() をそれらの前に置くことも必要です。
JCenter と Bintray は、信頼できるアーティファクトホストではありません。理想的なのはそれらから何も取得しないことです。

上から読んでいくリポジトリ群指定の最下位にオープンすぎる jcenter() を置くべし、と言っています。


repositories {

  //...
  mavenCentral()
  jcenter()
}

しかし、ワロタ。

android - Why does the Google maven repository exist and when should I use it? - Stack Overflow

Gradleが参照するリポジトリの優先順位について - Qiita