一応ソートのソースも追ってみたけれど、インデックス使ってないね。そもそもあのインデックスの作成方法で文字列型以外のソートができるわけないんだけども #realm
一応ソートのソースも追ってみたけれど、インデックス使ってないね。そもそもあのインデックスの作成方法で文字列型以外のソートができるわけないんだけども #realm
なんか、ちゃんと調べるほど絶望してきたし、 Sync に乗っかる予定がないなら使うべきではないプロダクトだなという印象になってきている #realm
> Indexing a property will greatly speed up queries where the property is compared for equality (i.e. the == and Contains operators), at the cost of slower insertions.
https://realm.io/docs/dotnet/latest/#indexed-properties
って書いてあるけれど、 String にしか効かないなんてどこにも書いてないし、意図的に隠されていると思ってるよ #realm
この前、行を削除すると遅くなるかもと言ったけれど、あれは半分間違いだった。少なくとも C# バインディングでは、行の削除をすると、削除して空いたところに一番最後の要素を持ってくる動作をするので、 General Form へ変換を行う必要がない #realm
realm-core(C++ 実装)では、行を本当に削除することも、最後の要素で埋めることもできて、バインディング側の実装が後者を呼び出してる #realm
https://github.com/realm/realm-dotnet/blob/71a799479c966febc36e62cc190d90b663bc2486/wrappers/src/object_cs.cpp#L385
これを erase(row_index, false) にすれば、本当の削除になる
RemoveRange も追ってみたけれど、やっぱり move_last_over しているので、 C# バインディング(object-store のコードで指定されているから他の言語バインディングでも)から General Form を生み出すのは不可能かもしれん。まぁそのために行番号には直接触れられないような API を公開してるんだろうけど #realm
ネットに転がる Realm のベンチマーク的な話を読むときは、 Realm のデータ構造は列指向ということに気を付けないといけない。クエリが完走しきった時点では行番号のリストを持っているだけで、実際にプロパティにアクセスしたときに、プロパティに対応する列の、行番号に対応するデータを取得しに行くので。 #realm
SQLite に詳しかったら比較してめっちゃ楽しい感じにできたんだろうけれど、もう1か月かけて SQLite の調査をする元気は残ってないよ。。。
(モバイル/web)アプリのバックエンドとかいう、リリースした時点で DB のユースケースが確定している用途なら、インデックス指向であるべきだと思う。
クエリ言語という観点でいうなら、どのカラムを条件にするか、ではなく、どのインデックス(または複合インデックス)を条件にするかで指定できるべき。
開発環境全体で言うなら、ユースケースから適切なインデックスを自動で生成できるべき。
とにかく、不要な全件検索を避けることに重きを置いて設計されるべきだと思う。
Timestamp 型カラムの出力に対応していなかったり、存在しないメンバーを呼び出していたりするあたり、オープンソース化前からすでにメンテされてないんじゃないか疑惑がある
ざるそばの人だからわけわからんラノベとして期待していたんだけど、特設サイトができてしまって、出版社が推す気、つまりまともな作品になってしまっている可能性が出てきて、つらくなってきた
MF文庫J『スコップ無双 「スコップ波動砲!」( `・ω・´)♂〓〓〓〓★(゜Д ゜ ;;;).:∴ドゴォォ』特設サイト http://bc.mediafactory.jp/bunkoj/scoopmusou/
ゴミ箱にティッシュを投げ入れるくらいのノリで、カードリーダーに学生証投げつけたら出席になってほしいので、やわらか素材の学生証が求められる