Hi Matthew,
thanks for the quick reply. We've been checking acs_attributes a bit more in detail, and the way ad_form lists and the extension tables are generated there. For us that looks very promising, because these plain extension tables are easy to add to an incredible number of existing "legacy" objects that we have in our systems (more then 100...), they are easily joined in SQL selects using a "select e.* from ... extension_table e" and they should have a good performance.
To put it the other way around: The "CR attributes plus trigger" option that you mentioned is definitely not going to work for us. We would need the "type_specific" storage.
However, the "type_specific" storage should fit nicely into the AMS, shouldn't it? It's really just a storage type, compared to the "cr" storage type that you proposed. And it is even already implemented in the OpenACS core.
So do you think that might be an option for you?
In the postitive case we would start working on the Oracle version nearly immediately, taking your current AMS code as a base and introducing what's necessary for the "type_specific" storage.
Bests,
Frank