Any downside to using both an in-memory constraint and a DB constraint?

Support
#1

I have a reference to User in each Entity and for each entity in the users access group I have a database constraint limiting {E}.user to session$user. I want to be really careful that users can only access their information.

Is there any downside to always having a similar in-memory constraint whether the entity might be loaded as part of the object graph of another entity or not?

I am concerned that if I, for example, expand functionality and add a previously un-accessed collection of a different entity to a view, it will all of a sudden not be filtered because it is now loaded in memory as part of the object graph.

If the answer is yes, is the Groovy script for the in memory filter the same “{E}.createdBy = :session$userLogin”?

#2

The only downside is some performance impact which depends on the complexity of your script. If you just check a local attribute on equality to some value, it should be minimal.

The Groovy script for checking agianst the user login is as follows:


{E}.createdBy == userSession.user.login

userSession is a variable of type UserSession automatically passed to the script.

#3

Ok. Thx. Incidentally, in a couple of cases I was using “{E}.createdBy = :session$userLogin” as my Groovy script and I thought that I was OK because when I hit the “Test Constraint” button it gave a positive message. I assumed it tested both database and in-memory constraints.

You should consider making the message clearer so there is no confusion that it only applies to the database constraint. Alternately, you could move the button to under the “Where Clause” box. It is now under both the “Where Clause” box and the “Groovy Script” box and gives the misleading impression it applies to both.

#4

You are right, will do.