Validate belongs_to between two different databases

Questions / Help
,
1

Hi :slight_smile:

In my umbrella app, with currently two apps, each based on its own DB…

I have a schema in app2 referencing a uuid from an object of app1 .

DB1 :
  Table : parent
    parent_id: uuid
    name: string

DB2 :
Table : child
    child_id: uuid
    parent_id: uuid
    name: string

Then the schema :

  schema "child" do
    field :name, :string
    belongs_to(:parent, Parent, type: :binary_id)

    timestamps()
  end

How to have the changeset validate that parent_id is valid and exists in its table ? I tried some things, like assoc_constraint(:parent) but tbh I knew it wouldn’t work… Maybe I just should rethink the relationship and how it works.

Thanks ahead.

2

You cannot have cross DB relations. If parent records aren’t deleted, then you can do it by additional query, if they can be deleted, then there is no way to check it and be 100% sure that there will not be difference.

3

I know corss DB FKs are not possible. The question is, how to validate efficiently the changeset in that case ? I was thinking of a custom validation function, that would go and request what is needed, returning false when need to… But then, surely it won’t be located in the changeset. So, if it’s the right way, where should it belongs ?

4

Why wouldn’t it belong in the changeset? If you need to call to a external service as part of validating the changeset then it is that way.

5

I just don’t like the idea of the changeset having some logic linked to another table… But again, I’m only starting with functionnal programming so I could be wrong.

6

If I understand the situation correctly … changeset is just a data structure. Custom validation is typically performed with validate_change/3 which is handed a validator function. And while that function’s arguments are only the field name and value, a function expression has access to anything in the enclosing scope.

So with validate_change you can involve any functionality in the validation process.

It’s probably also worthwhile to mention that foreign_key_constraint/3 and unique_constraint/3 don’t actually check the constraint at the time the function is called. They simply “prepare” the changeset - so if a DB-level constraint error occurs within the Repo operation the error can be readily converted to the appropriate changeset error (suppressing the exception).

3 Likes