You're quick. I'm glad you took this on and not me. The new schema is more where I was headed. The only things that I will be implementing differently are the parent-child relationship and identity. It appears you have made the relationship 1-to-many (parent has many children) while I will need to create a many-to-many relationship table. But I think a 1-to-many design is better for your base implementation.
The object identity difference I refer to is that my recipient can sometimes be the object being accessed. For example, a user may be granted access to another user (like an administrator role with specific users they may access). In my case, a recipient can also be in the acl_object_identity table with a parent and so on. Where this applies to your design is that you have recipient as a VARCHAR field not an id INTEGER from acl_object_identity. You may not want objects to have parents when they serve as recipient to a permission but that can be dictated in code by just not navigating the relationship of the recipient (is that confusing?). When the object serves as the entity on which permissions have been granted, that parent relationship could have value. Guess all I'm trying to say is that it would make sense to make the recipient an INTEGER constrained via foreign key to the id in the acl_object_identity table. For me this is worthwhile, what do you think? > Hi Andres > > I just checked into CVS the improvements. The end database schema is now > heavily normalised, with plenty of constraints to prevent incorrect data: > > CREATE TABLE acl_object_identity ( > id IDENTITY NOT NULL, > object_identity VARCHAR_IGNORECASE(250) NOT NULL, > parent_object INTEGER, > acl_class VARCHAR_IGNORECASE(250) NOT NULL, > CONSTRAINT unique_object_identity UNIQUE(object_identity), > FOREIGN KEY (parent_object) REFERENCES acl_object_identity(id) > ); > > CREATE TABLE acl_permission ( > id IDENTITY NOT NULL, > acl_object_identity INTEGER NOT NULL, > recipient VARCHAR_IGNORECASE(100) NOT NULL, > mask INTEGER NOT NULL, > CONSTRAINT unique_recipient UNIQUE(acl_object_identity, recipient), > FOREIGN KEY (acl_object_identity) REFERENCES acl_object_identity(id) > ); > > Do you have any further suggestions/feedback? > > Best regards > Ben > > > ------------------------------------------------------- > This SF.Net email is sponsored by OSTG. Have you noticed the changes on > Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, > one more big change to announce. We are now OSTG- Open Source Technology > Group. Come see the changes on the new OSTG site. www.ostg.com > _______________________________________________ > Acegisecurity-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
