I need some suggestions on how to deal with following situation. It might not be directly related to LLBL but here it goes. I have a entity that defines alert such as alert category and alert description and some other attributes. I have another entity that defines what users subscribe to this particular type of alert. Users also can override default attributes of the alert such as category and description. So now I have to provide a list of alert definitions with their description and category geared toward user. What is the best approach in doing this. I was thinking in creating a transient class that would merge those two. So I would get a list of user alert subsriptions, check which ones do not have overide values and then execute another fetch to alert definition to get a list of default values and then merge them. Is there a better approach, or some magical way that LLBL could do this for me.

I will not pretend to understand you query 100 % , but why not just a single de-normized entity that has all the fields i.e alerts, alert desc, users that subscribe to the alert, and their overides

I'll asume you have a table called Alert, which holds the difinition of the different available alerts (ID, Name, Category, Desc..etc).

Then you might have another table called UserAlert, which might contain the following (UserID, AlertID, AlertName, AlertCategory, AlertDesc...).

Now I can think of the following 2 approaches (personally I prefer the second approach)

Approach #1:

1- When a user register to an Alert, you should create a row in the UserAlert table and copy all the chosen Alert values into the corresponding fields in the newly created row. 2- When the user wants to modify default values, you will change them in the UserAert table 3- To view user alerts, always select from the UserAlert table

Pros: Easier on viewing the user alerts

Cons: harder on maintaining default values if the default values of an alert gets changed, you should check and see which UserAlert rows still has those default values (similar to those in the Alerts table), and then change them all in the same transaction.

Approach #2:

1- Create an extra field in the UserAlerts, let's call it "UseDefaults", and it's default value is true (1). Which determines if the user is using the default values or if he's using his own modified values

2- Create a database view to get the User defaults that you want, which might look like the following:

Select * -- have the fields Aliased
From UserAlerts
Where UseDefaults = 1
Union 
Select * -- Select the Alerts fields and have them Aliased to match the above query
From UserAlerts Inner join Alerts
Where UseDefaults = 0

3- Map the view to an Entity or TypedView

Pros: Easier to maintain, less code

Cons: harder on design time, carefull dealing with the "UserDefaults" flag is needed.

Thanks, Waala I opted for a third approach doing the merge in the PL. Problem with 2 is that there are multiple overriden attributes. So I get all alert definitions with one call, create a hashtable and then just loop through user ones and if any of the attributes is emty I replace it with a default one. Works fine for now.