Forum OpenACS Q&A: Re: Compatibility matrix and OpenACS 5.7

Collapse
9: Re: Compatibility matrix and OpenACS 5.7 (response to 1)
Posted by Jim Lynch on 06/05/12 08:13 PM
they are used... you can't not use them. there is a schema named public that's created by default, and everything is created inside that schema.
Collapse
10: Re: Compatibility matrix and OpenACS 5.7 (response to 9)
Posted by Jeff Rogers on 06/06/12 10:04 PM
This isn't using schemas, any more than tablespaces or toasted attributes are being used. Yes, they are being used but only because you can't not use them; but the additional functionality they provide isn't used.

They could be used as a namespacing mechanism; for example the calendar package might use a 'calendar' schema with a 'new' function within that schema (similar to oracle packages), and the function would be 'calendar.new' rather than 'calendar__new'.

Would there be any tangible benefit from doing so? Hard to say, it's mostly just a naming convention. But there also seems to be no downside, which is why wondering why they aren't used. (changing everything to using '.' instead of '__' is obviously a pretty big disruption of course)

Collapse
11: Re: Compatibility matrix and OpenACS 5.7 (response to 10)
Posted by Gustaf Neumann on 06/08/12 02:02 PM
yes, using SQL schemas would certainly make the system prettier.

The reason, why SQL schemas are not used in OpenACS is for historical reasons: when the postgres port was done, schemas were not supported by postgres. When using schemata, it would certainly make sense to move not only stored procedures into the schema space, but as well the tables defined by the packages, every package could be contained in a tcl namespace and sql schema ... and then, one should do the same for oracle as well. As you mentioned the benefit is not huge; from my experience is more likely that you get hate-mails, when you break something, than love-mails, when the components work as before.

I see a move to SQL schemas of less priority than Step-2 above (currently, debugging the function with the varying argument lists is painful, querying the default values from the postgres meta data does not work, we have hacks in OpenACS to work around this).