Question

First, some background:

I have a Company model, a Project model and a Task model. A Project belongs to a company and a Task belongs_to a Project.

The Project model holds several attributes: company_id, date. These attributes uniquely identify a project

I am letting the users create a task by API by POSTing to a URL that contains the details necessary to identify the Project. For example:

POST /projects/<comnpany_name>/<date>/tasks/

In order to make life easier for the users, in case there is no project with the given details, I’d like to create the project on the fly by the given details, and then to create the task and assign it to the project.

…And my problem is:

When there is a problem to create the project, let’s say that the company name is not valid, what is the right way to return the error message and communicate to the user?

I’ll explain what I mean: I added a create_by_name_and_company_name method to the Project:

  def self.create_by_name_and_company_name(name, company_name)
    if company = Company.find_by_name(company_name)
      project = Project.create(company_id: company.id,
                               name: name)      
    else # cannot create this project, trying to communicate the error
      project = Project.new(name: name)
      project.errors.add(:company, 'must have a valid name')
    end
    company
  end

I was hoping that by returning an unsaved Company object, with errors set, will be a good way communicate the error (This is similar to how rails work when there’s a validation error).

The problem is that when calling valid? on the company object, it removed the error I wrote there and adds the regular validation errors (in this case, company can’t be blank).

And a bonus question…

And there is a conceptual problem as well: since I’m creating a model by providing parameters that are being used to create the actual attributes, they doesn’t always map nicely to the errors[:attr] hash. In this case it is not so bad and I’m using the company field for the company name parameter, but I guess this can get messier when the parameters provided to the create method are less similar to the model attributes.

So what is the preferred approach to tackle that problem? Is there something basically wrong with that approach? if so, what is the preferred approach?

Answer 1

I figure that it is best to avoid such nesting and stick to a shallower API.