yesodweb / yesodweb/persistent
Cannot filter by composite foreign key
Nobody has claimed this yet.
- Dominant language
- Haskell
- Stars
- 486
- Forks
- 306
- PR merge metrics
- No merged PRs in 30d
Description
I would expect to be able to filter on a child related to a parent on the child's composite foreign key to the parent (the same way that I can access the foreign key using the generated accessor). The following test case might explain better what I mean:
diff --git a/persistent-test/CompositeTest.hs b/persistent-test/CompositeTest.hs
index b3829b9..b2d54c9 100644
--- a/persistent-test/CompositeTest.hs
+++ b/persistent-test/CompositeTest.hs
@@ -179,6 +179,16 @@ specs = describe "composite" $
c1 @== c11
testChildFkparent c11 @== kp1
+ it "Filter by Foreign Key from Child value" $ db $ do
+ kp1 <- insert p1
+ _ <- insert p2
+ kc1 <- insert c1
+ xs <- selectList [TestChildFkparent ==. kp1] []
+ length xs @== 1
+ let [Entity newkc1 newc1] = xs
+ c1 @== newc1
+ kc1 @== newkc1
+
#ifndef WITH_MYSQL
it "Tree relationships" $ db $ do
kgp@(TreeKey gpt) <- insert $ Tree "grandpa" Nothing
However, the TestChildFkparent constructor is not generated by Peristent's TH (while the testChildFkparent accessor is). This would be very useful for generating join conditions using Esqueleto. This is related to https://github.com/prowdsponsor/esqueleto/pull/87 and https://github.com/prowdsponsor/esqueleto/pull/88
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the proposed regression test in persistent-test/CompositeTest.hs and inspect how Persistent's TH generates the testChildFkparent accessor. Trace the related composite foreign-key generation and Esqueleto references from the linked issues. Done means the TestChildFkparent constructor is generated and the filtering test passes.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- haskell
- Domain
- database
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100