Frans, i ve been checking the tinyforum application and i must admit you ve done a great job. i think its a pretty well designed and outlined web application.

I have a question about one thing thou. you have ActionRights enum decleration in globals.cs and the first item has the value 1. And in SessionAdapter class you have a method called CanAdministirate

public static bool CanAdministrate() { ActionRightCollection actionRights = GetSystemActionRights(); if((actionRights == null) || (actionRights.Count <= 0)) { return false; } // use FindMatches to determine if there are actionrights present which allow administation. List<int> toFind = new List<int>(); toFind.Add((int)ActionRights.SystemManagement); toFind.Add((int)ActionRights.SecurityManagement); toFind.Add((int)ActionRights.UserManagement);

        return (**actionRights.FindMatches((ActionRightFields.ActionRightID == toFind**)).Count > 0);
    }

ok the question is: when you use FindMatches to find if there is any matches between the 3 ActionRights (systemmanagement, securitymanagement...) and users actionrights how can you be sure of what is coming from the database? ActionRights.SystemManagement has the value 3 for example, how do you know ActionRightFields.ActionRightID for systemmanagement is 3 in database? it could be any integer since its an identity field.

maybe i am missing something. could you please tell me how it really works there? thank you

-shane

With this kind of thing, it's a little awkward: you have to define the values somewhere and re-use these same values elsewhere. I decided to define them in an enum and re-use the defined values in the database.

ActionRight.ActionRightID isn't an identity field btw:

CREATE TABLE [ActionRight] (
    [ActionRightID] [int] NOT NULL ,
    [ActionRightDescription] [nvarchar] (50) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL ,
    [AppliesToForum] [bit] NOT NULL ,
    [AppliesToSystem] [bit] NOT NULL ,
    CONSTRAINT [TF_ActionRight_PK] PRIMARY KEY  CLUSTERED 
    (
        [ActionRightID]
    )  ON [PRIMARY] 
) ON [PRIMARY]
GO

So the same values are stored in the table. Yes, this might be 'shaky' perhaps, but there's no other way to do this: the code must know that '1' means actionright X and not Y, so the best place to do that is in the code, i.e. an enum. That values in the db might be changeable, so be it: you can't prevent that anyway, one can switch the descriptions for 1 and 2 for example.

(btw, Walaa and others have also written code for HnD )

I understand, thank you for the explanation. Well congrats to Walaa and the others also

One more question (forgive me being a curious george please): you chose to keep the user object, his system action rights, forum action rights and audit actions all in a session object. Wouldnt this kind of exhaust the server if too many users access it at the same time? Keeping all above objects in a session object must be different than keeping only a userid i guess?

Is it really a good practice?

thank you -shane

e106199 wrote:

I understand, thank you for the explanation. Well congrats to Walaa and the others also

One more question (forgive me being a curious george please): you chose to keep the user object, his system action rights, forum action rights and audit actions all in a session object. Wouldnt this kind of exhaust the server if too many users access it at the same time? Keeping all above objects in a session object must be different than keeping only a userid i guess?

Is it really a good practice?

thank you -shane

If you have many thousand of concurrent users, then yes, it might be memory intense, however the alternative is to re-fetch user stuff every time the data is required (which can be quite often), which is also not that great.

So I chose the session cache route, as this forum doesn't have thousands of concurrent users at the same time. Also the data is quite small, so it's not that intensive as it might look

Otis wrote:

So the same values are stored in the table. Yes, this might be 'shaky' perhaps, but there's no other way to do this: the code must know that '1' means actionright X and not Y, so the best place to do that is in the code, i.e. an enum. That values in the db might be changeable, so be it: you can't prevent that anyway, one can switch the descriptions for 1 and 2 for example.

I'm wondering if a lot of people find this to be a gap during the development process: an enum's value needs to be kept synchronized with a database table that represents the same thing.

I ask because I wrote a small framework (using LLBLGen Pro of course!) that manages this, which I could share if people find it interesting. So instead of writing SQL scripts to make sure these stay in synch, the system can be set up to keep itself in synch.

It's far from perfect, but we like it here.

Phil

Phil i would love to see what you have. can you please email it to me at ulkerim AT gmail DOT com

thank you

-shane

If you have many thousand of concurrent users, then yes, it might be memory intense, however the alternative is to re-fetch user stuff every time the data is required (which can be quite often), which is also not that great.

So I chose the session cache route, as this forum doesn't have thousands of concurrent users at the same time. Also the data is quite small, so it's not that intensive as it might look

Thank you yes i think its better than re-fetching the data each time it is required.

-shane

e106199 wrote:

Phil i would love to see what you have.

I will try to clean it up and post something this weekend.