O/Rマッピングは、従来の煩雑なデータベースに関する処理の記述をスマートにし、、柔軟なアプリケーションの構築を可能にします。本連載ではオープンソースのO/Rマッピングフレームワーク「Hibernate」を用いてO/Rマッピングの基礎を解説します。そしてさらに、J2EEアプリケーションへの実践的な適用方法とそのメリットも紹介していきます。（編集局）
O/Rマッピングは、従来の煩雑なデータベースに関する処理の記述をスマートにし、、柔軟なアプリケーションの構築を可能にします。本連載ではオープンソースのO/Rマッピングフレームワーク「Hibernate」を用いてO/Rマッピングの基礎を解説します。そしてさらに、J2EEアプリケーションへの実践的な適用方法とそのメリットも紹介していきます。（編集局）
このエントリでは、Yegor Bugayenkoによる記事、ORM Is an Offensive Anti-Patternを紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。 結論から言えば、ORMはオブジェクト指向プログラミングの原則の全てに違反するひどいアンチパターンだ。オブジェクトをバラバラに引き裂き、もの言わぬ受身なデータ入れに変えてしまう。 小さいWebアプリケーションから、数千のテーブルをCRUD操作するエンタープライズシステムまで、どんなアプリケーションにもORMが存在することはゆるせない。 代わりになるものは? SQLを話すオブジェクトだ。 ORMの仕組み オブジェクト関係マッピング (Object-relatinal mapping、ORM
peewee は Python でデータベースを扱いやすくする「 OR マッパ」ライブラリです。 デフォルトでは PosgreSQL 、 MySQL 、 SQLite の 3 つに対応しています。 以下 peewee の基本的な使い方を見ていきます。 データベースへの接続 データベースへの接続は Database クラスのインスタンスを使って行います。 SQLite の場合は次のようになります。 # データベースに接続する db = SqliteDatabase('db.sqlite') db.connect() # さまざまな処理... # データベース接続を閉じる db.close() # データベース指定のための設定を格納したベースモデル class BaseModel(Model): class Meta: database = db # モデル Person # person テ
I'm starting a new application and looking at using an ORM -- in particular, SQLAlchemy. Say I've got a column 'foo' in my database and I want to increment it. In straight sqlite, this is easy: db = sqlite3.connect('mydata.sqlitedb') cur = db.cursor() cur.execute('update table stuff set foo = foo + 1') I figured out the SQLAlchemy SQL-builder equivalent: engine = sqlalchemy.create_engine('sqlite:/
この記事は PHP Advent Calendar 2013 8日目の担当記事です。 昨日は brtriver さんの "PHP Fatal error: Allowed memory size of xxx" で落ちる前にできること という記事でした。 はじめに 今日は、Slim という軽量フレームワークと Idiorm & Paris という 軽量ORM という軽軽コンビの紹介です。 Slim 公式ドキュメント Idiorm & Paris Idiorm 公式ドキュメント Paris 公式ドキュメント composerがインストールされていない場合はこちらを参考に、インストールしておいて下さい。 Composer サンプルコードの想定環境は PHP5.3.0 以上 MySQL 5.* です。 ※ データベースはPostgreSQLやSQLite等、PDOが対応していれば利用可能です。
Making queries¶ Once you’ve created your data models, Django automatically gives you a database-abstraction API that lets you create, retrieve, update and delete objects. This document explains how to use this API. Refer to the data model reference for full details of all the various model lookup options. Throughout this guide (and in the reference), we’ll refer to the following models, which comp
Google グループでは、オンライン フォーラムやメール ベースのグループを作成したり、こうしたフォーラムやグループに参加したりすることで、大勢のユーザーと情報の共有やディスカッションを行うことができます。
思いのほか前回のRailsプチ・デザインパターンの紹介に反応があったので、こういう小ネタも出していったほうがいいのかな、ということで第二弾。 ソーシャル系アプリだと、ユーザとユーザを関連付ける多対多のモデルがたくさんでてきます。たとえば、一般的なところではフォローとかブロックとか足あととか。さらにデーティングサイトになると、ウィンクだったり、Secret admirer（こっそりlikeするけど両思いだったらおめでとうって通知がくるってやつ）だったり、いろいろなモデルがこのパターンにあてはまります。 この場合、「AがBをフォローしている」「BがAをフォローしている」「AとBがお互いにフォローしている」という3つの状態があるわけですが、相互フォローの状態は「AがBをフォローし、かつBがAをフォローしている」と読み替えてSQLでも記述可能なので、以下ではシンプルに単方向のグラフで全てを扱うもの
Perlでデータベースに接続する場合は以下の様な感じになります。どんなORMなりラッパーなりもDBIを利用しているモジュールは内部的にはこういうことをしているわけです。 DBI->connect($dsn, $user, $password, { mysql_enable_utf8 => 1, RaiseError => 1, PrintError => 0, ShowErrorStatement => 1, AutoInactiveDestroy => 1, }); 第1〜第3引数は環境によって差異があるので設定ファイルに情報を持たせると思います。ただ、それにつられて第4引数も設定ファイルに書いてしまうのが散見されますが、これは良くない。 第4引数の値はプロジェクトでは固定に決まっているので、設定ファイルによって自由度を持たせる必要性が全く無いというかむしろ悪。この人の環境ではテストに通
find_or_create的なやつは大体どんなORMでも レコードを探す 無かったらINSERT みたいに実装することになると思う。ただこれだと、1と2の間でレースコンディションでエラー起きることがある。他のプロセスがINSERTしてしまうとかそういうやつ。 それを防ぎたい場合に、1の時点でFOR UPDATEするのはすごくダメで、空行にFOR UPDATEしたりするとMySQLだと盛大に乙るのは有名な話。 エラーを起こさないで、確実にレコードを取りたい場合にはどうすればよいかというと、以下のようにするのが良いと思っている。UNIQUEキー制約なりがちゃんと付いている前提。サンプルコードはTengの場合。 sub find_or_create_surely { my ($self, $table, $where, $opt) = @_; my $row; my $txn = $self-
C#に続き、ASP.NET Advent Calendar 2012です。前日は84zumeさんのWebFormっぽいコントロールベスト3でした。私はC#ではMemcachedTranscoder - C#のMemcached用シリアライザライブラリを書きまして、ああ！これこそむしろASP.NETじゃねえか！と悶絶したりなどして、日付逆にすれば良かったよー、困ったよー。しかもあんまし手持ちの札にASP.NETネタがない！というわけで、ASP.NETなのかビミョーですが押し通せば大丈夫だろう、ということでMicro-ORMについて。 Micro-ORM? 最近タイムリーなことに、またORM論争が起こっていて。で、O/R Mapperですが、私としては割と否定派だったりして。C#にはLINQ(to SQL/Entities)があります！はい、色々な言語のORMを見ても、LINQ(to SQL/
サンフランシスコのプログラマLaurie Voss氏が書いた見逃せない記事が賑わっています。近年のフレームワークやライブラリの定番中の定番ORマッパーが既にアンチパターンなのではというのが彼の主張です。この記事を書くきっかけになったのはこのツイートだそうです。 I cannot overstate the degree to which ORM is a dangerous antipattern. — Laurie Voss (@seldo) June 9, 2011 ORM が危険なアンチパターンだっていうのはどれだけ言っても言い過ぎることはない このツイートに対して各方面(ActiveRecord, Doctrine, Hibernate)から多くの（激しい）返信が寄せられて書かれたのが問題のエントリです。まずはアンチパターンとは何かの定義として下記の2つを挙げています。 当初は有益
謎社のデータアクセスはMicro-ORMでやっています。生SQL書いて、シンプルなPOCOにマッピングするだけの。ですが、そこで困るのはPOCOの作成。データベースの写しなだけのクラスですが、手で作るには、ひじょーに面倒。Entity Frameworkならドラッグアンドドロップで！DataSetですらホイホイと作れるのに、100%手作業とか嫌だよー、200テーブルを延々とクラス作るだけの刺身たんぽぽなんてしてたら死んじゃうよー。 というわけで、Micro-ORM使うなら避けては通れない定義。EFのクラス定義だけ流用しちゃうとか色々と逃げ道も考えられなくもないですが、もしくは数によっては手動で頑張ってしまうのも手ですが、ここは自動生成しましょうの会。 GetSchema 普通にSQLのクエリを書いてデータベースの情報を取ってくることも可能ですが、各データベースでそれぞれバラバラだったりする
FuelPHPの物理削除と論理削除の実行結果メモ
FuelPHP1.5.3にて、以下の組み合わせに対して、それぞれ親Modelからdeleteメソッドを実行してみました。その結果をメモしておきます。尚、実行環境はMAMP(Mac)のPHP5.4.4、ドライバはPDOです。 (1) 親: 物理削除モデル / 子: 物理削除モデル (2) 親: 論理削除モデル / 子: 論理削除モデル 初期化用SQLは以下です。各組み合わせの実行前に、このSQLで初期化しました。 -- ----------------------------------------------------- -- Table `parents` -- ----------------------------------------------------- DROP TABLE IF EXISTS `parents` ; CREATE TABLE IF NOT EXISTS
私がDjangoのORMを気に入っているのは、Pythonコードでスマートにクエリセットを作れるからです。 例を書いてみる。 blog/models.py from django.db import models import datetime class Entry(models.Model): title = models.CharField(max_length=100) content = models.TextField() create_date = models.DateTimeField(default=datetime.datetime.now) def __unicode__(self): return self.title こんなモデルを作った。 Qオブジェクトを使ってクエリセットを作ってみる In [1]: from blog.models import Entry
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
