Upsert in Slick 3 - Underscore
Upsert in Slick 3 Posted 14 Jul 2015 by Richard Dallaway An upsert means inserting a row into a database if it doesn’t already exist, or updating the row if it does exist. The Slick database library knows how to do upserts. This posts takes a look at the built-in support, and gives an example of what you can do if you need to roll your own upsert logic. This is part of a series on Slick, for mater
slickにおけるトランザクション管理 – rinoguchi's techlog
scalaのデータベースライブラリとしてslickを業務で使ってみようと試していたが、ドランザクション管理に制限があり、最終的に取りやめることにした。調べたこと、試したことを備忘録的に残しておこうと思う。 slick version : 3.3.0 slickの基本 slickではクエリに相当するDBIOActionというものをまず生成する。以下の例だとinsertやupdateがDBIOActionに当たる。また、insertとupdateを合わせたactionもDBIOActionに当たる。 次に、db.run()でアクションを実行することにより、実際にSQLが実行される。 val insert = Hoge.map(h => (h.item1, h.item2)).++(Seq((11, 12), (21, 22)) val update = Hoge.filter(_.item1
SlickにてAutoincrementされたIDを取得して別テーブルにInsert | 50ぱーせんとおふ
SlickでAutoincrementされたIDを追加時に取得し、そのIDを使用して他のテーブルにもレコードを追加する方法 例えばAccountにユーザーを追加、IDはautoincrementされるが、そのIDを利用して他のテーブルにもIDに結びついたレコードを追加したいような場合。 の方法。 環境は play2.4 Slick3.0 mysql 普通にレコード追加して、そのIDを取得する方法としてはオフィシャルドキュメントに載ってるとおり Slick3.0.3 Manual http://slick.typesafe.com/doc/3.0.3/queries.html#inserting val userWithId = (users returning users.map(_.id) into ((user,id) => user.copy(id=Some(id))) ) += U
Scala Testing With Databases - 2.9.x
Testing your application Testing your Application Testing with ScalaTest Writing functional tests with ScalaTest Testing with specs2 Writing functional tests with specs2 Testing with Guice Testing with compile-time Dependency Injection Testing with databases Testing web service clients Main concepts Section introduction Configuration API HTTP programming Asynchronous HTTP programming The Twirl tem
Play flyway プラグインを作りました - tototoshi の日記
https://github.com/tototoshi/play-flyway Play にはもともと Evolutions というデータベースマイグレーション機能がついていますが、それと同じような機能を Flyway で作りました。 Flyway は Java 製のデータベースマイグレーションライブラリなんですが、Java でコードを書いたり、XML を使ったりではなく、Evolutions と同様に、Plain な SQL ファイルを使うのが基本です。 http://flywaydb.org/ Motivation 1 (重要) Play の Evolutions Plugin って実は DBPlugin に依存しているので、DBPlugin を使わない人にとってはちょっともどかしいところがあります。DBPlugin を使わない人ってのは例えば Mongo とか使ってる人 Scali
MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]
株式会社ラクーンホールディングスのエンジニア/デザイナーから技術情報をはじめ、世の中のためになることや社内のことなどを発信してます。 bashパフォーマンスMySQLInnoDBDB設計インデックス こんにちは、羽山です。 今回は MySQL のプライマリキーに UUID を採用する場合に起きるパフォーマンスの問題を仕組みから解説します。 MySQL(InnoDB) & UUID のパフォーマンスについては各所でさんざん議論・検証されていますが、論理的に解説した記事が少なかったり一部には誤解を招くようなものもあるため、しっかりと理由から理解するための情報として役立つことができればと思っています。 UUID と比較される古き良き昇順/降順のプライマリキーはというと、 MySQL の InnoDB において良いパフォーマンスを出すために縁の下の力持ちのような働きをしてくれているケースが実は少な
![MySQLでプライマリキーをUUIDにする前に知っておいて欲しいこと | Raccoon Tech Blog [株式会社ラクーンホールディングス 技術戦略部ブログ]](https://cdn-ak-scissors.b.st-hatena.com/image/square/5e9d48c3c6f38c2d5f71897d98efcb251289d1f9/height=288;version=1;width=512/https%3A%2F%2Ftechblog.raccoon.ne.jp%2Fwp-content%2Fuploads%2F2021%2F07%2Fboard-755792_800.jpg)
Oracle SQL実行計画の読み方 | コーソルDatabaseエンジニアのBlog
渡部です。SQLチューニングの基本は、実行計画への理解です。 過去のdb tech showcase発表のスライドがよくまとまっている（自画自賛！）ため、これを用いて実行計画の読みかたを説明したいと思います。 db tech showcase 2017「Oracle入門セミナー 実行計画を読んでみよう！」 2017年9月のdb tech showcase 2017の発表を下敷きにして、実行計画の読みかたを説明します。 db tech showcase 2017「Oracle入門セミナー 実行計画を読んでみよう！」 https://cosol.jp/techdb/2017/09/dbts2017-oracle-read-execution-plan-html/ SQLチューニングの省力化・自動化にはToadのSQL Optimizer for Oracle, SQL Optimizer fo
PostgreSQL アップデート時のタイムスタンプ自動更新 - IT技術で仕事を減らしたい！
どうも、NIPPAです。 データベースを利用していると、最終アップデートの日時を保存しておきた場合があります。 MySQLでは、テーブル作成時に定義することで自動的に更新日時を格納してくれる機能がありますが、 PostgreSQLでは工夫が必要になります。 今回は、PostgreSQLでもデータ更新時に更新日時自動でアップデートする方法のご紹介になります。 環境 PostgreSQL Functionについて Functionの設定 Functionにトリガーを設定 Functionの削除 感想 環境 PostgreSQL10.12 PostgreSQL Functionについて PostgreSQLでFunctionの機能を使って、自動更新する方法をご紹介します。 PostgreSQLのFunction機能は、テーブルが更新された際に指定されたカラムに対して処理を自動で行う機能になります
履歴テーブルについて - 一休.com Developers Blog
この記事は一休.com アドベントカレンダーの25日目の記事です。 レストラン事業部エンジニアのid:ninjinkunです。 一休.com及び一休.comレストランはユーザー向けのシステムだけではなく、店舗や一休内の管理者向けの業務システムという性格も持っています。 業務システム経験の無かった自分が一休に転職して最初に驚いたのが、DBに履歴を保持するための履歴テーブルが大量にあることでした。 そこから履歴テーブルの存在に興味と疑問を持ち、社内外のエンジニアと履歴テーブルについて議論してきました。このエントリではそれらの議論をまとめた結果について書いていきます。 履歴テーブルのパターン まず以下の図をご覧ください。 込み入った図かつ事例が一休特化で恐縮ですが、左上の起点から始まって、右のオレンジの部分が最終的な実装パターンです。 図にあるとおり、たいていのユースケースでは以下の3パターンの
データ履歴管理のためのテンポラルデータモデルとReladomoの紹介 #jjug_ccc #ccc_g3
3. 2 Agenda 1. 自己紹介 2. RDBMSで履歴データを扱う スナップショットデータモデル トランザクション時間データモデル 有効時間データモデル バイテンポラルデータモデル 3. Javaからバイテンポラルモデルを容易に扱うReladomoの紹介 hashtag: #ccc_g3 4. 3 自己紹介 趣味：ドラム演奏 JavaOneコミュニティバンド Null Pointersで演奏経験あり（日本人初） Tech Lead @ FOLIO 伊藤 博志 Eclipse Collections：共同プロジェクトリード兼コミッター Reladomo：コントリビューター OpenJDK：コントリビューター JJUG CCC、Java Day Tokyo、JavaOne San Francisco登壇 2017年5月17日に株式会社FOLIO入社。 hashtag:
slick-doc-ja 3.0 — slick-doc-ja 3.0
slick-doc-ja 3.0 Slick 3.0 documentationの日本語訳です。 編集先: GitHub - krrrr38/slick-doc-ja 連絡先: @krrrr38 他のバージョンのドキュメント Slick 1.0 翻訳 Slick 2.0 翻訳 Slick 3.0 翻訳 API Documentation (scaladoc) Slick Core (slick) TestKit (slick-testkit) Code Generator (slick-codegen) Direct Embedding (slick-direct) (Deprecated) Slick Extensions (slick-extensions)
DBマイグレーションを行う技術 - 発明のための再発明
データベースのスキーマを変更するということはデータをいじる行為であり、最悪の場合データが消えます。 最悪の事態にはならなくとも、思わぬ場所に影響が起きたり、データの不整合が発生する恐怖と戦う必要が有ります。 テストや切り戻しを含めて計画し、大きな変更の場合にはダウンタイムまで考慮する必要があります。 そこで、RDBを対象にデータベースの変更を行う方法について書いていきます。 スキーマ変更 まずは、スキーマ変更について、 カラムを追加する 一番簡単で、影響も少ない変更です。 気をつけるのは、 ソースコードの変更よりも前にスキーマ変更を完了させる (長時間)ロックがかからない方法を選ぶ といったところでしょうか。 大抵の場合は、スキーマの変更とソースコードの変更の順番にさえ気をつければ問題は発生しません。 カラム名を変更する 「ALTER」でさくっと変えたくなりますが、ソースコードの変更が同時
MySQLでトランザクションの4つの分離レベルを試す - FAT47の底辺インフラ議事録
トランザクションとは 1つの作業単位として扱われるSQLクエリの集まりです。 複数のUPDATEやINSERTをひとつの集まりとして、 それらのクエリがすべて適用できた場合のみデータベースに反映します。 ひとつでも適用に失敗したクエリがあった場合は、そのまとまりすべてのクエリの結果は反映しません。 ACID特性 トランザクション処理に求められる4つの特性です。 原子性 (Atomicity) トランザクションに含まれる手順が「すべて実行されるか」「すべてされないか」のどちらかになる性質。 一貫性 (Consistency) どんな状況でもトランザクション前後でデータの整合性が矛盾なく保たれる性質。 分離性 (Isolation) トランザクション実行中は、処理途中のデータは外部から隠蔽されて他の処理に影響を与えない性質。 永続性 (Durability) トランザクションが完了したら、シス
Railsアプリケーションで採用しているDBスキーマ設計ガイドライン - LCL Engineers' Blog
Webエンジニアの森脇です。 Railsアプリケーションで採用しているDB設計（スキーマ定義）について紹介します。 ※ Railsでは当たり前もの、Railsに依存していない内容も含んでいます。 前提 環境違えば、採用するルールも異なると思いますので、まずは弊社で利用している環境を記載します。 DBはPostgreSQL 9.x 開発言語は、Rails 4.x,5.xを利用 命名ルール Railsの規約に沿う命名を採用しています。DB設計にこだわりがあるメンバーにとっては、異論があるルールもあるのですが、アプリケーション開発の生産性も考慮しRailsの規約に寄り添うのがよいと判断をしました。 テーブル 動詞は使用せず、名詞とする 複数形とする 1:n のテーブル名は「単数形_複数形」 とする n:n のテーブル名は「複数形_複数形」とする カラム カラム名にテーブル名のprefixは付与し
なぜAWS LambdaとRDBMSの相性が悪いかを簡単に説明する - Sweet Escape
2020/01/20 Update: 本エントリの内容は2019年12月3日にアナウンスされた『Amazon RDS Proxy』のリリースにより完全に陳腐化しました。過去のアンチパターンがフィードバックをもとにした改善によってアンチパターンではなくなるという最高の事例です。 サーバーレス元年始まった！ 今年がサーバーレス元年な理由. それはLambdaに以下が揃ったから. ・カスタムランタイムで実質どんな言語でも利用可能 ・VPC利用時のコールドスタート改善 ・Provisioned Concurrencyでスパイク対応も可能 ・RDS ProxyでRDBとの接続が現実的に これまで5年で受けたフィードバックがついに結実. 強い— Keisuke Nishitani (@Keisuke69) 2020年1月19日 RDS Proxyの詳細はこちらからどうぞ。まだプレビューですがぜひ試して
Hibernateはどのようにして私のキャリアを破滅寸前にしたか | To Be Decided
このエントリでは、Grzegorz Gajosによる記事、How Hibernate Almost Ruined My Careerを紹介する。 (Grzegorzから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 想像してくれ。 君はJava開発者で、次のビッグプロジェクトを開始しようとしているところだ。 君は、そのプロジェクト全体に影響する根本的な決断をする必要がある。 君の柔軟なデータモデルをオブジェクト指向で抽象化するベストな方法を選択したい。生のSQLを扱いたくはないからね。 どんな種類のデータもサポートしたいし、理想では全種のデータベースをサポートしたい。 すぐに思いつくのは、単にHibernateを使うという解だ。そうだろ？ Javaディベロッパの90%は君に同意するだ
MySQLを１〜２時間でスケールアウトする - クックパッド開発者ブログ
最近、Elastic BeanstalkやECSと戦っているSREチームの菅原です。 P5をやりたいのにPS3もPS4も持っていないので指をくわえて羨ましがっている毎日です。 この記事では、突然のアクセス増に備えるために、MySQLのスレーブを１〜２時間でスケールアウトできるようにした話を書きます。 MySQL on EC2 クックパッドは周知の通りAWSを利用していますが、主要なデーターベースについてはAmazon RDSではなくMySQL on EC2を使っています。 これは以下のような理由によるものです。 歴史的な経緯: AWS移行当時、RDSが無かった。また、移行後もしばらくはTritonnを使っていたため、RDSを使うことができなかった オンラインメンテナンスの実現: VPCルートテーブルを使った仮想IPとMHA for MySQLを使ってダウンタイムゼロのマスタDBの切り替えを
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Can Slick's insertOrUpdate modify a subset of columns in the event the record already exists?
Testing Play Framework with H2 in-memory database
herokuのデータベースをローカルにリストアする
