Forum OpenACS Development: Missing package_ids in acs_objects: get via context_id ?

I have a couple of content_items (and others) which do not have a package_id in acs_objects (old system).

I was wondering if going over the data using the context_id path is a bad idea, or more precise, would result in incorrectly found package_ids

Here is my idea:

db_foreach object_without_package_id {select object_id from acs_objects where package_id is null and context_id is not null} {
  set object_type ""
  set ref_object_id $object_id
  while {$object_type ne "apm_package" && $object_id ne ""} {
    db_0or1row context_id "select context_id,object_type from acs_objects where object_id = :object_id"
    if {$object_type ne "apm_package"} {
    set object_id $context_id
    }
  }

  if {$object_type eq "apm_package"} {
    db_dml update_package_id "update acs_objects set package_id = :object_id where object_id = :ref_object_id"
}
}

Sadly my old instance has over 6000 objects which meet the above criteria so I could only check it worked as promised for 10 files.

That will fail, I think, if you reach an object with context_id null, as happens when permissions inheritance is turned off for an object.

So you probably want to guard against that ...

I stumbled upon both of the problems, that is why we have the check against the object_type in the code as well as the check if object_id is "null". As we set the object_id to the context_id, if context_id is null it will not further execute.

Either way, it is, as Gustaf pointed out, only a migration issue and maybe someone finds this helpful once they stumble upon the same problem.

If they are content items you can also check up the content item hierarchy for a package_id. Ie: check parent_id, until you get to the root. You can also check if the parent_id is a folder and if cr_folders.package_id is set.
the context-id is not guaranteed to be a package_id, but for many packages it is. It is also possible that the context_id is a package_id from a different package, but i am not aware of any package, that does this....

However, you should check, if the context_id (or in your code snippet, that i don't understand fully, the variable object_id) is indeed a package_id, otherwise the foreign key constraint acs_objects_package_id_fk will barf on invalid package_ids....

other than this, it should improve the situation. In general, that should be only a migration problem, since well behaved OpenACS 5.* packages should provide the package_ids in acs_objects for every new object.