Gunnar R|nning wrote:
> Serialization is not a good solution with the current version of postgres,
> I think 7.1 will offer some improvements there(the new TOAST
> implementation).
>
> What kind of data is contained in these hashtables ? Different user/group
> attributes ?
The hashtable is probably most usable in Role class. Sometimes you need
to assign a role some permission that is not represented in a satisfying
way by a binary flag (that's how I see Permission object). Sometimes
you wish to assign an Integer, a String or any other Java object.
This is where custom attributes for a Role come in...
It's less useful (at least to me with) Permissions and Groups, but I
provided
it for symmetry.
The reasoning behind using serialized hashtable, is that it's impossible
to know in the advance what attributes the user will need for his
application.
We could use the same approach as in TurbineUserPeer - you can call it
adaptive
peer, because it will use real columns for attributes if they exist,
hashtable
otherwise, but :
1) Role's et al. attributes don't need to be searchable (or at least I
can't
think of any use for that)
2) You have to deal with the situation where user set's an attribute and
there
is no column for it. It's easier to deal with if we have the
hashtable handy.
> If so, are there any good reasons to not use a table with key/value pairs
> instead ? These would also allow you to do queries directly against
> attribute table.
We could have 4 different attribute tables, or one table with additional
column
indication what class the attribute belongs to. Either way we have
additional
complexity (and in the latter case bad db design). The hashtables seem
to
be the easiest way to go (but I'd like to hear other developer's
opinions)
I understand that dealing with binary objects is inefficient in PSQL.
This should
not bother us much, as the new security system caches the security
objects
(Roles, Permissions) in memory, so the checking user's permissions in
the
normal flow of the application does not involve any DB traffic. Only the
administration application would suffer some performance impairment.
> Is the new Security setup in the current CVS or do I have to get it from a
> branch ? I was planning on using the security part of Turbine for an
> application, so I would love to take a look at the new code.
just run
cvs co -d "turbine-security" turbine -r security_01-branch
and take a look at these packages:
org.apache.turbine.services.security
org.apache.turbine.om.security
org.apache.turbine.om.security.peer
org.apache.turbine.util.security
I hope we'll be able to merge it into the trunk some time next week.
Rafal
--
Rafal Krzewski
Senior Internet Developer
mailto:[EMAIL PROTECTED]
+48 22 8534830 http://e-point.pl
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
