mORMot Open Source

tbo

Member

Registered: 2015-04-20

Posts: 353

Updating dependent ORM objects

Following situation:
I have master articles. There can be article variants of each master article in the same table. If a master article is changed, all derived variant articles must also be updated. Is the following source code a good pattern on server side (Interface based service) to achieve this? Are there things that are important to keep in mind?

function TArticleService.Update(const pmcItem: TOrmArticle): Boolean;
  ...
  // If a master article is changed, all derived variant articles must also be updated
  if (pmcItem.IDValue > 0)
    and (pmcItem.MasterArticleID = 0) then
  begin
    // Load all variant articles
    restServer.Server.RetrieveListObjArray(articleList, TOrmArticle, 'MasterArticleID=?', [pmcItem.IDValue]);
    try
      if restServer.Server.TransactionBegin(TOrmArticle) then
      try
        // Save master article
        if restServer.Server.Update(pmcItem) then
        begin
          // Update variant articles
          for i := Low(articleList) to High(articleList) do
          begin
            ...
            restServer.Server.Update(articleItem);
          end;
        end;

        restServer.Server.Commit;
        Result := True;
      except
        restServer.Server.RollBack;
      end;
    finally
      ObjArrayClear(articleList);
    end;
  end
  ...
end;

With best regards
Thomas

ab

Administrator

From: France

Registered: 2010-06-21

Posts: 14,659

Website

Re: Updating dependent ORM objects

Just thinking out loud.

If I understand correctly, your concept of "master article" is similar to a template, or the master slide in PowerPoint.
In a relational model, you would have two tables, and let the variant articles take the information from the master table, using a join.
I guess you are closer to the Aggregate model here.

Some remarks in respect to the Aggregate model:

1. First of all, I would not use TransactionBegin+Update, but a TRestBatch for the modifications. It will be easier to code, and also faster.
Your data should not have to rollback anyway, because the DB should never fail, just persist the data.

2. The concept of aggregate don't have much interest outside of the notion of bounded concept boundaries.
You are still focusing on the data. I would define several services, with two repositories. Or a single service, but two well defined aggregates, because they have two contexts.

3. If you need to update several articles, then your don't properly implement the Aggregate pattern. The Aggregate should be a single ORM instance. So the variant articles should be stored as a single ORM instance, depending on the bounded context.
So in fact, your code should consist just in TWO Update() calls, one for the master article, another for the variant articles - all linked together within a single class.
To be more efficient, the Update() may only occur on some fields, but it would change everything at once, using a single ORM class instance each time.

4. And if you have proper Aggregates defined, then even the Batch would not be needed any more. Just two Update() calls would be enough.