Eric Dobbs <[EMAIL PROTECTED]> writes:
>On Monday, July 8, 2002, at 10:55 AM, Henning P. Schmiedehausen wrote:
>> The Turbine-2 Security System (and the Fulcrum Security System) have a
>> column called OBJECTDATA in their respective User Peer classes.
>>
>> Turbine-2 actually uses it in o.a.t.om.security.peer.TurbineUserPeer
>> around line 282 and serializes and deserializes the permStorage
>> Hashtable into the OM objects.
>>
>> Fulcrum never seem to touch it. Neither in the TurbineUserPeer nor in
>> the TurbineUser objects itself. Am I just blind or did this
>> functionality break when moving the DBSecurityService onto Torque
>> peers.
>Henning,
>If I remember correctly, the OBJECTDATA fields were being abandoned
>because they cause problems for portability. In particular, there
>are a number of hacks in the code to make Postgresql play nicely
>with them and the hacks seem to cause endless trouble for those who
>use Postgresql. So I think it was removed purposefully, but from
>the sound of your description it may not have been removed
>completely.
>-Eric
Hi,
the whole point of the setPerm()/getPerm() methods seems to be moot if
you don't have proper serialization of the permStorage array.
I have already code, that simply uses the Torque provided VARBINARY
fields and leaves it to Torque to do proper locking (PostgreSQL can
only access BLOB under a Transaction).
This is in the DB Security Service proposal. I might factor out the
code for current Fulcrum (it's pretty simple). The alternative is
deprecating the whole setPerm()/getPerm() stuff.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
D-91054 Buckenhof Fax.: 09131 / 50654-20
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
