It's either a bug in the interface OR a bug in the API code (and possibly the underlying data model). If application code uses the CR API as documented, the CR should behave accordingly.As I mentioned in my previous post, I'm OK with removing the option if nobody sees an immediate use for changing the storage_type on existing items. That's certainly the easiest thing to do.
I vote for this option. Michael's entirely correct, the API should match the datamodel. If storage_type isn't in cr_revisions it shouldn't be offered as a param in cr_revision::new.
Now - how much code will taking it out of the API break?
A history lesson - storage type was an OpenACS addition to ACS 4. My idea, actually, to allow the choice, but mostly implemented by Dan Wickstrom.
I think this datamodel/API mismatch arose because at the time we were just learning the core code (very different than ACS 1-3) while breaking pieces out from tcl files into XQL files, porting queries, inventing the tree structure code for PG to overcome lack of connect by, etc etc.
In other words, Dan and/or I just made a boo-boo because this feature, while important, from a coding point of view was really quite minor.
So it's a bug from the beginning of the OpenACS porting effort ...
