Forum OpenACS Development: Re: AMS package ams_options

Collapse
Posted by Dave Bauer on
I think the ultimate answer might be to store all the attributes for one type in one table, how regular objects do. I am looking into using contacts, and AMS, and so far, I don't see a way to implement what I need using these packages, even though I think the idea of a contacts package is the right model.

The code I am thinking of converting to contacts adds a complementary object with all the attributes we want to use to extend person. This seems much more efficient and, using the ability to arrange attributes into differnet forms, the user should never notice the difference if all the attributes are in one table, or stored in generic storage.

The other thing that bothers me about contacts is that it extends person, instead of creating an extension type that is related to a person object. This isn' a big deal though, I can see how it will work either way.

Collapse
Posted by Malte Sussdorff on
I like this approach. So basically you talk about generating a "ams_${object_type}_values" table with columns for the object_id and each of the attributes (where the column is named with the attribute name and not the id).

I think this should be fairly easy to achieve taking into account that not too many procedures need to be changed (namely the one for attribute generation and the ones for attribute retrieval).

Not sure what impact this would have though on the contact searches (brr...). Maybe Matthew can elaborate on that one?