Forum OpenACS Development: Re: package_id for acs_objects

Collapse
Posted by Dave Bauer on
For title, object_type_object_id is clearer.

For package_id, i think the package_id of the acs_subsite its created under? That should be straightforward if it is created from a page request. I am not sure how to do that from a scheduled procedure.

Collapse
Posted by Timo Hentschel on
The default title i assign is the pretty_object_type_name followed by the object_id if i cannot get a better title. So, this is not really the problem.

I don't have much of a problem with objects created by a package - even in acs-subsite or whatever. But what to do with objects created in the ACS-CORE? Like i said, what to do with relationships, users, groups, events, service-contracts, authorities etc etc etc??? These objects are all created during system installation thus there is no real package that creates them - but there are package_ids of acs-kernel, acs-events etc - should i use them?

Collapse
Posted by Guan Yang on
As for package_id, how about this simple rule: If in doubt, objects belong to the package that contains the SQL file where acs_object_type__create_type is called.
Collapse
Posted by Timo Hentschel on
Well, the thing is, for objects created during install there is no package_id yet, is there? so, should i assign null then?
Collapse
Posted by Dirk Gomez on
What would be the other options? Claim that they "inherit" from "Main Site" maybe?
Collapse
Posted by Timo Hentschel on
How should they inherit? and when? as i said, during install there is no package_id available - not even of "Main Site".
Collapse
Posted by Mark Aufflick on
this is a bogus idea, but here goes:

  • you make a temp table:

    ___________________________________
    | fake_pkg_id |    package_key    |
    +-------------+-------------------+
    |    -1000    |    acs-subsite    |
    |    -1001    |   acs-templating  |
    |     ...     |        ...        |
  • you use the fake package id's to populate the acs_objects table
  • as soon as package_id's exist, you reverse lookup the real package_id's using the package_key and replace the fake id's in acs_objects.
of course there is a limitation for packages mounted more than once during install, but if that (unlikely) event occurs, you could just use the first one and still be in a sensible position. it may be possible to even correctly deal with that situation, but i'm not too familiar on how package_id's are created during bootstrap.