Forum OpenACS Development: Re: AMS package ams_options

Collapse
Posted by Matthew Geddert on
Thinking off of the top of my head converting AMS skinny to AMS generic storage would pose these problems, all of which are not insurmountable but its reasonably tricky:

1. Postgres has a limit of the number of columns that can be in a table, so we might need to create secondary storage tables for sites with many attributes, i.e. persons, persons1, persons2, etc.

2. we would want contact and mime_type for all richtext widgets, etc. So the oclumsns do add up

3. Multiple widgets (checkbox, multiselect) would likely require a column per option (and then be true, false or null), this could mean many, many columns are needed

4. I think it would make sense to store revisions in skinny and live data in the type specific storage type, that way searches and retrieval are fast for live data and the revisions are still there and a bit slower. Speed for frequently accessed data, efficient storage for infrequently accessed data.

5. Re-writing the storage part of ams to deal with type specific shouldn't be too difficult. Re-writing the contacts searches related to this would likely be a lot more tricky (or at least time consuming).

Anyways, I can think of a lot more specific concerns but this I think sums up the main conceptual issues related to such a re-write.

Collapse
Posted by Malte Sussdorff on
To make our life easier at the moment, we should probably have the generic approach added in addition to the the skinny one, thereby reducing the need to rewrite all the search queries. Though the data entry into the skinny tables should happen in a lazy fashion, meaning that the website should return once the value has been stored in the generic storage and not wait for the values to be safed in the skinny storage as well.

1) I think we might not have to think too hard about it. I do agree this problem exists, but if someone really hits this constraint, then we can add the person1, person2 extension.

2) Though this might sound strange, why don't we store the content *always* in text/html. We can do a conversion before storing if the mime_type was text/plain.

3) Bad idea with the one column per option. I would save the selected options in a list within the generic storage. Though the benefit only works with simple display, on edit we need to work with the option_ids again...

4 + 5) Yeah. This also helps us with the searches (as the searches work on revisions anyway and the live revision is in the skinny tables anyway).

All in all I think we should go down this way. Now the question which arises for myself could we do the generic storage using dynamic types? I mean, this is what dynamic types does in the first place or did I miss something here?