# How to Reuse Relations Across Slices in Hanami?

**URL:** <https://discourse.hanakai.org/t/how-to-reuse-relations-across-slices-in-hanami/1173>\
**Category:** questions\
**Created:** [March 5, 2025, 4:03pm UTC](https://discourse.hanakai.org/t/how-to-reuse-relations-across-slices-in-hanami/1173 "2025-03-05T16:03:41Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![panteo](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/panteo/32/824_2.png) [@panteo](https://discourse.hanakai.org/u/panteo)\
**Post date:** [March 5, 2025, 4:03pm UTC](https://discourse.hanakai.org/t/how-to-reuse-relations-across-slices-in-hanami/1173/1 "2025-03-05T16:03:41Z")

</div>

Hi everyone,

I’m new to Hanami and trying to structure my application correctly. I need some guidance on how to properly share relations across slices.

Since relations define our low-level data sources, my understanding is that they should be defined once and reused in repositories across different slices. Is this the recommended approach? If so, how can I achieve this?

For example, I have a relation defined in `app/relations/books.rb`, and I want to use it in my `slices/web/repos/book_repo.rb`. However, when I try to reference it in the repository, I get the following error:

```sh
undefined local variable or method 'books' for an instance of Web::Repos::BookRepo

```

Here’s a simplified version of my setup:

#### Relation (Defined at the application level)

```ruby
# /app/relations/books.rb
module MyApp
  module Relations
    class Books < MyApp::DB::Relation
      schema :books, infer: true
    end
  end
end

```

#### Repository (Inside a slice)

```ruby
# /slices/web/repos/book_repo.rb
module Web
  module Repos
    class BookRepo < Web::DB::Repo
      def all
        books.to_a
      end
    end
  end
end

```

What is the correct way to access the `books` relation inside my slice’s repository? Should I be explicitly importing or registering it somewhere?

Any help or best practices would be greatly appreciated!

---

<div class="post-metadata">

**Author:** ![panteo](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/panteo/32/824_2.png) [@panteo](https://discourse.hanakai.org/u/panteo)\
**Post date:** [March 5, 2025, 7:48pm UTC](https://discourse.hanakai.org/t/how-to-reuse-relations-across-slices-in-hanami/1173/2 "2025-03-05T19:48:47Z")

</div>

Hi everyone,

I believe I’ve found a solution after reading a great [discussion](https://discourse.hanakai.org/t/integrating-rom-into-hanami-2-2/971/2) in this forum.

To properly share relations across slices, the slice **should not have its own `db` folder**. You can achieve this by generating the slice with the `--skip-db` option:

```sh
hanami generate slice web --skip-db

```

Additionally, it’s necessary to enable relation sharing by configuring the application to import database settings from the parent:

```ruby
module MyApp
  class App < Hanami::App
    config.db.import_from_parent = true
  end
end

```

Does this approach align with best practices, or am I unintentionally relying on a side effect?

Any feedback or recommendations would be greatly appreciated! 😊

---

<div class="post-metadata">

**Author:** ![alassek](https://yyz2.discourse-cdn.com/flex030/user_avatar/discourse.hanakai.org/alassek/32/532_2.png) [@alassek](https://discourse.hanakai.org/u/alassek)\
**Post date:** [March 6, 2025, 5:10am UTC](https://discourse.hanakai.org/t/how-to-reuse-relations-across-slices-in-hanami/1173/3 "2025-03-06T05:10:59Z")

</div>

> [@panteo](#):
>
> am I unintentionally relying on a side effect?

No, this is precisely what `import_from_parent` is intended to do. I believe you have the right mindset here; Relations defined in `app/` that are shared across slices, and slice-specific Repos is what I would recommend.

However, there’s no harm in having Slice-specific Relations, depending on how specialized the scope logic gets. If you end up collecting stuff in your Relation that doesn’t belong in other Slice contexts, splitting that up is an option. But you probably don’t need to start out like that.