Smart Relationships

This is the official documentation of the agent_ruby Ruby agent.

Smart relationships are very different between the two versions of the Agent.

You can find the full documentation of relationship customization here.

Structure

Smart relationships on legacy agents were declared creating a smart field with a reference property but differed in the way that:

• Relationships to a single record (many-to-one or one-to-one) worked using the get function which needed to return a single record.

• Relationships to a list of records (one-to-many or many-to-many) worked by implementing all the CRUD routes on a router file.

The new system is completely different: it is based on primary keys and foreign keys.

Migrating

Relationships when the foreign key is accessible

Before

# Model
class Forest::Product
  include ForestLiana::Collection

  collection :Product

  has_many :buyers, type: ['String'], reference: 'Customer.id'
end

# routes.rb
namespace :forest do
  get '/Product/:product_id/buyers' => 'orders#buyers'
end

mount ForestLiana::Engine => '/forest'

# Controller
class Forest::ProductsController < ForestLiana::ApplicationController
  def buyers
    limit = params['page']['size'].to_i
    offset = (params['page']['number'].to_i - 1) * limit

    product = Product.find(params['product_id'])
    customers = Customer.where(order_id: product.orders.ids)

    render json: serialize_models(customers.limit(limit).offset(offset), meta: {count: customers.count})
  end
end

After

Relationships when you need complex logic to get a foreign key

In this example, we want to create a relationship between the order collection and the address collection (assuming that it does not already exist in the database because depends on complex logic).

We can see that in the legacy agent, the delivery_address field was a smart field that returned the full address of the order, while in the new agent, we will create a computed field that will contain the address ID (the foreign key), and then create the relationship.

We won't be detailing the migration of a relation to a list of records here, but it is very similar to the one described below.

If the foreign key was already present in the database in a related table, use the import-rename-delete feature to move it to the correct collection instead of using a computed field.

This will be much faster and will not require In filter operators to be implemented (as unlike computed fields, imported fields are natively filterable and sortable).

Before

class Forest::ProductsController < ForestLiana::ApplicationController
  def buyers
    query = # complex query

    render json: serialize_models(query, meta: {count: query.count})
  end
end

After