問題タブ [haskell-persistent]

Yesod でリソース用の REST API を作成しています。指定されたリソースを作成しようとする POST メソッドがあり、成功した場合は 201 と新しく作成されたリソースの ID を返します。例えば、

これは私が得るエラーです。これは十分に明白です：

の何かが欲しいのはわかっていますが、Database.Persist.ClassToTypedContentの からそれを取得する方法が見つかりません。Keyどんな助けでも大歓迎です。

編集：

実際のリソースの定義は次のとおりです。

persistent-templateエンティティを宣言するために使用できることは理解していますが、既存のデータベースからそれらを構築するためのツールはありますか? 具体的には、MySQL データベースを指定して Persistent で使用できる定義を返すツールはありますか?

Servant で Persistent を使用しようとしているので、URL セグメントを Persistent キーに自動的に解析する余裕がありません。代わりに、 を要求するようにルートを設定しましたInt64。それを使用してレコードを取得し、主キー ルックアップを実行したいと考えています。

私が見つけたものはすべて 、整数をキーに変換するために使用することを示しているので、それを行う非常に単純な関数を作成しようとしました:toSqlKey

残念ながら、これはうまくいきませんでした。次のタイプのエラーが発生しました。

私はgetこのエラーをある程度理解しています —との型を調べたところtoSqlKey、関連する制約が含まれています。

私が正しく理解し、同じタイプである必要があるbackendが、制約を適用すると、タイプが一致しなくなります。私の直感では、 であるはずですが、明らかに間違っています。理由や方法はわかりませんが。PersistEntityBackend valtoSqlKeySqlBackendPersistentEntityBackend (Entity Record) SqlBackend

とにかく、その分析が正しいか間違っているかはわかりませんが、いずれにせよ、これを修正する方法やこれを行う適切な方法はわかりません. 整数を指定してデータベースからレコードを取得するにはどうすればよいですか?

この質問はgroundhogまたはに関するものですpersistent。どちらも同じ問題を共有していると私は信じているからです。

Tr m aいくつかの機能を提供するトランスがあるとしますf :: Int -> Tr m ()。この機能には、データベースへのアクセスが必要です。ここで使用できるオプションはいくつかありますが、満足できるものはありません。

DbPersistのどこかに変圧器を置くことができTrます。実際には、標準のトランスフォーマーのインスタンスがなく、さらにnewtypePersistBackendのインスタンスを作成する必要があるため、これを一番上に配置する必要があります。Trクラスが最小からかけ離れているため、これはすでにひどいものです。私が行うすべての db アクションを持ち上げることもできます。

もう 1 つのオプションは、 の署名を に変更するfことPersistBackend m => Int -> Tr m ()です。これもまた、私のnewtype でPersistBackendインスタンスを作成するか、リフティングする必要があります。Tr

ここからが本当の問題です。すでに制約Trがあるコンテキスト内で実行するにはどうすればよいですか? PersistBackendと共有する方法はありませんTr。

最初のオプションを実行して、いくつかの新しい接続プールDbPersist内で実際のトランスフォーマーを実行するTrことができます (私が既にいるコンテキストからプールを取得する方法がないことがわかる限りPersistBackend)、または 2 番目のオプションを実行することができます。実行関数を にしますrunTr :: PersistBackend m => Tr m a -> m a。2番目のオプションは実際には完全に問題ありませんが、ここでの問題は、DbPersist最終的にスタックのどこかになければならない が、現在トランスフォーマーの下にあり、構成されている標準トランスフォーマーのインスタンスTrがないことです。PersistBackendTr

ここで正しいアプローチは何ですか？現時点では、ReaderTリクエストに応じて接続プールを提供するスタックのどこかにセパタレrunDbConnを使用し、DB にアクセスしたいすべての場所でそのプールを使用するのが最善の選択肢のようです。DbPersist基本的にすでにそれがいかに重要であるかを見ると、ReaderTそれをしなければならないことに意味がありません。