TSKaigi 2024 ref: https://tskaigi.org/talks/tockn
現状Cloudflare D1で使用できるORMとその使用方法ついてに纏めておこうという自分のメモを兼ねた記事です。記事中でRemixとの組み合わせで書いてますが、最後のSuperflare以外はRemixは特に必要ありません。 前提条件 ORMだけでなく、Databaseのマイグレーションも出来て運用に耐えるものを選択 今回の記事ではできるだけ実運用に耐えうるものを書いてみました。 まとめ Kyselyはクエリビルダーだけあって、ORMでは届かないSQLを書き足す場合には採用の価値あり D1だけで見るとDrizzleは意外と使える。(Prismaに比べると見劣るのは仕方ない) Superflareはまだまだアルファの域を出ないのでProductionでは採用出来ない。 今の所、初手で選ぶなら Drizzle >= Kysely >>>>>> Superflare かなという印象です。 K
sqlite 用に特化したORMを作りたい 何を作るか 主に sqlite 用のクエリビルダ + マイグレーションキット クエリビルダ部分は prisma 風の TypeScript の型推論をガンガン効かせたやつ。select するとそのフィールドだけ結果に出るやつ。 Why 最近 sqlite-wasm が sqlite 公式から出たので、ブラウザから sqlite を使う頻度も増えそう sqlite3 WebAssembly & JavaScript Documentation Index d1 や lite stream 等の各種の sqlite replication 系のDB が最近増えてるから sqlite の注目度が上がってる(俺の中で) 現状、cloudflare d1 も sqlite-wasm も sql を生で書かないといけない TypeScript になれた世代の
tl;dr 生産性を上げる & SQL インジェクションを防ぐために ORM を使うのがよいとされている(諸説あります) cloudflare workers + d1 はウェブの破壊的イノベーション(諸説あります) モダンフロントエンドで大切なのは TypeScript との親和性と言われている(諸説減ってきた) 本当は理想の ORM を自作したいのけど、drizzle が現状一番自分のゴールに近いので、試したら良さそうだった 既存の問題と drizzle-orm 今までのあらすじ というわけで d1 に全振りするのが今後の生存戦略として有効だと思っているんですが、d1 client は専用のAPIからクエリ文字列を送り込む形式なので、native driver を使ってる prisma や typeorm 等が使えません。 自分が Mongodb + たまに Rails ActiveR
はじめにTechnogoly Innovation Group 辻です。Go には Gorm や SQLBoiler をはじめとして様々な ORM があります。2021 年には当社のブログで OR マッパーの連載を行ったこともありました。絶対的な ORM があるわけではなく、業務システムの特性やチーム構成などに合わせて ORM を選択することになるでしょう。 今回、私たちのチームでは、バッチ処理が中心的な業務システム開発において Go の ORM に sqlc を採用しました。素の SQL を書いていくチームの開発方針1とマッチし、開発体験は非常に良かったです。一方、枯れきってはいない ORM ではあります。いくつか想定外の挙動が発生し GitHub の Issue を見ながら問題を切り分けることもありました。 これから sqlc を導入してみようかな、と考えている方々の参考になればと思い
Yesterday, Diesel released its first stable release. Diesel is the most productive way to interact with databases in Rust. Now that we’ve entered a period of stability, let’s take a look at what Diesel is about, and what makes it different. Truly Type SafeDiesel’s core goal is to prevent most runtime errors at compile time. To do this, we create a representation of your database schema in Rust’s t
Introduction Diesel (http://diesel.rs) is an ORM (Object-relational mapper) and Query Builder written in Rust. It supports Postgresql, Mysql and SQLite. It makes use of Rust's custom derive functionality to generate all the code you need in order to get all the power of Rust's type system when interacting with a database. This means that you get compile-time validation of your code, thus eliminati
(deftable user () (name :type text :uniquep t) (age :type integer :indexp t) (company :foreign-key 'company :nullp nil)) (loop for user in (filter 'user (:< :age 25)) do (format t "Company: ~A~&" (name (deref user 'company)))) Non-opinionated Crane doesn't drink the ORM Kool Aid: You won't spend a single minute struggling with an interface that claims to be “simple” yet forces you into a limited v
「O/Rマッパー」や「ORM」と聞くだけで顔をしかめる人もいらっしゃいます。たぶん過去にひどい目にあったんでしょうね。その大きな理由の一つがパフォーマンスでしょう。 一昨年のYAPC::Asiaに参加したとき、ORMは使うなという話を4回くらい聞いたのが印象的でした。DBのデータはハッシュで返すか、DBIをそのまま使うほうが良いと。弊社でもパフォーマンス上の問題をわかりづらくしてしまうことから、ORMを使用しないプロジェクトがいくつかあります。 まあ、そりゃDBI使うほうが高速に動くとは思います。 しかし、僕が使っているのは実用的な言語であるCommon Lispです。実行効率と抽象化がとても得意な言語です。さらに優れたオブジェクトシステムであるCLOSも仕様に含まれています。 そこで、既存のO/RマッパーにCommon Lispらしさを加えてみるとどうだろう。 そう思って作ってみたのが、
CURD - Tiny ORM for MySQL¶ Release: v0.3.6 (Installation) NOTE: CURD.py may not be stable before version 1.0 NOTE: version 0.3.0 has a lot of Not-Backward-Compatible changes compared to version 0.2.5. Tests status: CURD.py is a tiny orm for mysql database, written in Python. >>> from models import User >>> user = User(name='Tom', email='tom@gmail.com') >>> user.save() # insert 1L >>> user.email =
Tweak Pony ORM to meet specific requirements or develop a complete app using Python, TypeScript and ReactJS. The team of software development experts from our partner AgileCode can provide custom development for your project. Email us to info at ponyorm.org with a summary of your needs and we will give you an estimate of time and price. Get estimate Using Pony object-relational mapper you can conc
December 07, 201208:49 カテゴリプログラミングmysql O/Rマッパーはなぜ悪か タイムラインで「SQL上級者こそ知って欲しい、なぜO/Rマッパーが重要か?」ってのを見かけて居ても立ってもいられなくなったので、既出を承知で反論しておきたい。 スライドだけから話の内容を推測すると、 -- 販売成績上位10個を抽出 select * from sales where deleted = false order by amount desc limit 10 といったSQLを Sales.active().top(10).all() のように、細かく分解した部品を組み合わせて表現できた方が便利だし構造的でしょ?という話のようだ。 これは確かに一見美しいのだが、これこそが「敷居を下げすぎて、dbの性質を分かってない人まで気軽にSQLをいじるようになった結
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く