Tutorial 03 – Project Tutorial

What We Learn

Deploying new content that extends the model, but does not add elements to existing objects. How yellow Role classes are converted to standalone links, how state tracking works for previously loaded data that does not exist in the source anymore, as well as how soft deletion can be implemented in the Model layer using parameters.

Modeling and mapping

Look at the structure and content of the ProjMaster.PROJECT, ProjMaster.PERSON_PROJECT and ProjMaster.PROJECT_ROLE tables in DS_DemoData.

You will come to the conclusion that the following steps need to be taken:

In a new Project management subfolder, model the three new classes like below. Re-use the existing Person class, which leads to automatic integration of person data from both source systems.

Next decide on the keys: from the source data you can draw the conclusion that Project number is most likely the Business key for Project (the database table’s primary key is not of any help here), and Code would appear to be the Business key for Person’s role in project. Project membership, however, is worthy of a discussion.

Project membership represents a typical Participation pattern: something participates in some activity in a specific role during a specific period of time. It would make sense that the natural key in this case consists of the combination of the referenced classes as well as the Start date attribute, since a person could be in the same role in the same project during different times, or in different roles at the same time, and the key should be able to cater for all of these needs. It is technically possible that, even though the key feels logically sound, that some of the key values could change (for example, if someone corrects an error in the role, or if the person simply starts at a later date).

A change like this makes a hash key representing the same real world event to “change”, leaving us with two instances describing the same thing, but with slightly different details. To catch this, turn on State tracking for the Project membership class and set the Soft Delete parameter value to true after deployment. This can be done when we know we will always load the complete set of data representing the class. So in this case, we will always load all Project membership data, and we want to track when a previously loaded membership disappears for whatever reason. Note that soft deletion requires the state tracking to be active, but state tracking does not necessitate that you activate soft deletion.

To finalize the latest additions:

The Project membership key in the Key editor:

Open the existing ProjMaster mappings file and add the source columns to the mapping rows, and if needed, complete them with PK and FK info and the appropriate Class and Property names.

Save the project and build the entire model.

Try out an Ad Hoc diagram to verify your table structure. Start by selecting the Project management submodel in Models, click Open Implementation in ER Diagram, and then use the show/expand buttons in the diagram pane’s toolbar to work your way towards the structure below.

Deploy the changes & Soft Delete

In the Models pane, make a selection that contains the three new classes and deploy like in the previous tutorial. After deployment, during Step 2 below, select the Project membership class from the Models hierarchy, and set its Soft Delete parameter to true. Also try toggling the Soft Delete parameter on and off, and note that the corresponding view will react immediately by hiding or showing rows that are marked as deleted.

Run Tutorial Scripts

Run each of the tutorial script commands from the Help -> Tutorials -> DSharp Studio Professional Course -> Project Tutorial menu, and inspect the results.

Next tutorial