Matthew said: " I'm still not sure how we would know what table to look in for the values associated with that object_id. I'm hoping Don or Dave can explain this further. Would we add another field to acs_attributes? The acs_attributes table stores what attributes the original object uses, not what the "sub object" is being referred to."
You can use the same technique as you did to retreive the information for the original object. That is, once you have the related object_id you can query the object type definition to find out how to get the attributes of the related object. I think there will be two ways to get the attributes. A Tcl proc that would support generic and specific stored attributes. And a view that would only be able to get type specific storage attributes similar to the ones now used in the content repository.
Re: generic storage of data, the resoning is that the existing system works, so we should work with the existing system as much as possible. If we later find we need to expand it to include storage for other datatypes, we can change it at that time, but this should reduce the initial complexity of the implementation. Don and I felt that generic storage of attributes would be more rare, and any instance where precision or greater performance is required would indiciate type specific storage of the attributes.
