mkPersist :: MkPersistSettings -> [EntityDef] -> Q [Dec]

A problem with this is that the generated declarations don't know about any of the EntityDefs that are not provided as part of this invocation. So if you have two blocks, one of which defines User and another defining an Organization with a user UserId field, the foreign key won't get properly invoked, since the liftAndFIxKeys machinery won't find the User in the existing map of tables.

This would fix #1073 as well. That issue has some good exploration on why this particular problem impacts foreign key generation. persistent figures that a BlahBlahId type is a reference to a BlahBlah model, and it tries to find the BlahBlah model in a Map HaskellName EntityDef that it constructs... from the [EntityDef] that is passed in.

A work-around is to... well, pass them in!

module Foo where

    share [mkPersist sqlSettings, mkEntityDefList "fooDefs"] [persistLowerCase|

        Foo
            name Text
    |]

module Bar where

    import Foo

    share
        [ mkPersist sqlSettings . mappend fooDefs
        , mkEntityDefList "barAndFooDefs"
        ] [persistLowerCase|
         
            Bar
                foo FooId
                name Text
    |]

This requires that you do that . mappend dependentDefs for each one. But it should fix the issue.

It's a bit annoying to tease these relationships together manually. And it's very easy to forget, especially since, well, everyone pretty much has. Can we do better?