Documentation:OCLps Example

Here's a small model to show how to use the PSEval value. (This could also be interesting if you're working with associations.)

How is this stored? It is stored in the database as one table for the article, one table for the SysUsers, and one table for the comments. This is like two multi-links with one in one end and many here.

The expression for that is: SysSingleton.oclSingleton.CurrentUser. This is done here is so that the SysUser won't have tens of thousands of comments. We select from the comments an article that, in this case, points to the self - because this navigation starts from the article, the self here is article. We take the first comment because this is a collection, but we know for a fact that this will be the only one. Looking at how we can increase the performance or the performance problems that we could have here, we must decide whether we're going to show a list of articles or one article. There would be a problem because if we are showing, for example, a hundred articles with a thousand comments, that means there are a hundred thousand comments. We need to load it into memory and sum it up. If we were to use the article view which shows the content, we would want to show how many likes this article has gotten and the list of comments which could also be a list of articles. We still want to show the like count and we have three different implementations of how to show the like count. One way would be to say article.comments and select for the likes and then show the number. That would require the system to load every comment object into memory and then filter out the ones that have like, that is not null and see how many they are.

We decide to use the PSEval value. We want an integer. We use the PSVAL value and we say self.comments - this is basically the same as it would be in the OCL. PS (persistent storage) says we can do this in SQL and not load the objects. We take the comments, select the ones that are liked and take the size of it. In this case, we are also subscribe to the article which means that this would be re-evaluated if the article changes.

This will work well to show how many likes you have. If the user likes or unlikes, this value would not change. .

We will use PSVAL to get all the comments for this article into memory, but only the ones that have like on them. It would still load objects, but not all of them, only the liked ones up to 9,999 in this case, and then we would take the size of that. By loading the objects, we can take this size here after we have loaded the objects.

Another alternative would be to combine OCLPS and PSEval with OCL. We first pick out the comment the user has made. Then we find all the comments and all the objects that have liked on it, except my comment object and sum these up. We load all the objects except my own objects, and we add my own comment - liked status - manually.

This part will be executed in OCLPS

(insert image)

and this part will be in OCL

(image).

The next variant would be to have this as an integer. Now, this should be the PSEval value. We have the integer and calculate the value of every comment except mine. In OCL, which is auto-subscribed, we calculate the liked form for only my comment.

The effect of this will be that the UI will update when I like or unlike it, but if someone else does it, it won't update until my session reloads. It will feel like it's responding right away to my like setting, but to other like settings, it will delay because it will only reload when this value is needed the next time. It's slightly off, but I don't think anyone will notice and it's a huge performance boost.