Forum OpenACS Improvement Proposals (TIPs): Re: TIP #132 Plans to address storage_type problem in CR

Collapse
8: Re: TIP #132 Plans to address storage_type problem in CR (response to 1)
Posted by Michael Steigman on 05/14/09 05:09 PM
Gustaf - I was not arguing necessarily for ability to change the storage_type of an existing item. I was looking for feedback about whether it's useful or whether that was even the original intent. You may be right that the original intent was not to allow the changing of storage type. In fact, the PLSQL API does NOT have that storage_type option which would back that interpretation up. If we go with that interpretation, then you are exactly right - it's a bug in the interface. It's not, however, a bug in the portrait code. 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.

Collapse
9: Re: TIP #132 Plans to address storage_type problem in CR (response to 8)
Posted by Don Baccus on 05/14/09 05:27 PM
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 ...