Forum OpenACS Development: [OACS 5.10.0] permission::permission_p_not_cached - Changed from returning integer to char

Hi,

I have been working on upgrading some of our older OpenACS applications to OACS 5.10, and I have encountered issues with the boolean value returned from a permission check with the latest 5.10.1d18 ACS Kernel.

I found that the returned value from the API call permission::permission_p_not_cached changed from "1" to "t" for a true between 5.10.0 and 5.10.1d33 of the ACS TCL Package.

Is there a reason for this change, and was there any guidance for managing the upgrade process?

I understand that for consistency purposes we want to move from the char/integer to a more boolean value validation, but the change will break legacy applications.

ACS Tcl Library 5.10.0

permission::permission_p_not_cached

...
db_string select_permission_p {

select acs_permission.permission_p(:object_id, :party_id, :privilege)::integer from dual

}
...

ACS Tcl Library 5.10.1d33

permission::permission_p_not_cached

...
db_string select_permission_p {
select acs_permission.permission_p(:object_id, :party_id, :privilege) from dual
}
...

Is there a reason for this change

Yes, Oracle compatibility. Oracle has on the data model no Boolean data type, leading to errors like [1]. Historically, "permission::permission_p" was returning char also in the PostgreSQL versions, but it was changed on the PostgreSQL side to boolean some time ago (I think in OpenACS 5.9), ignoring at this time the Oracle side. The new version works identically for all regression tests of acs-core with PostgreSQL and Oracle databases.

guidance for managing the upgrade process?
The new version (returning in the Oracle style "t" or "f") is highly compatible on the Tcl level, since these values are accepted boolean values.

% set result t
t
% string is boolean -strict $result
1
% string is true -strict $result
1
% if {$result} {puts hello-world}
hello-world

However, you should not rely on comparing the boolean result of "permission::permission_p" with "0" or "1".... which is a potential source for incompatibility. If this is the case, change code like

if {[permission::permission_p ...] == 1} {...}
to
if {[permission::permission_p ...]} {...}

Let me know if I can be of any help

all the best
-g

[1] https://github.com/openacs/openacs-core/commit/5ed1a035a17b7fa62a71d3c7267b138131ff112d

Thank you for your quick answer, Gustaf.

And I think in our case it is more on the adp side since most of the examples in [1] were not unary, so with a glance the true/false validation wasn't used and instead we went with the eq/ne validation.

I still think it will be important to make the notice in the release notes for the 5.10.0 release [2] or at least make it clear since while I was searching for an answer I wasn't able to find it.

Again, thank you very much for your explanation.

[1] https://openacs.org/doc/acs-templating/tagref/if
[2] https://openacs.org/doc/release-notes

Good points. i've updated the documentation page slightly and added a hint to the forthcoming release notes.
Thank you for considering my comments. I saw the update in the documentation already.
Good suggestions are always welcome!
Brian, many thanks for the info. Good to know!

Oracle 23c is available since a couple of months. From my experience, Oracle users of OpenACS belong to the most conservative ones when it comes to updates. Forcing those to upgrade won't be an option (especially, when the database is not only used for OpenACS).

It is possible with the .xql files to write different code for newer and older Oracle versions, but this makes testing even harder... So, it will take still a while until we can converge in this respect.

Brian, has your company already upgraded to Oracle 23c?

Hi Gustaf

no, it will be a long time before we will upgrade to 23c. We have definitely been on the conservative side with doing upgrades!

Brian