Hi,

Is there a way to filter every entity automatically my a field eg. CustomerID?

At startup of my Application the Current CustomerID is set in a global class. Now I want that every fetch adds a filter for that CustomerID automatically.

Exsample:
A table T_Foo with two rows:
  ID CustomerID ...
  1  1
  2  2

//...
FooEntity foo;
Global.CustomerID = 1;
foo = new FooEntity( 1 ); // => Ok
foo = new FooEntity( 2 ); // => Error (not found)

//...
Global.CustomerID = 2;
foo = new FooEntity( 1 ); // => Error (not found)
foo = new FooEntity( 2 ); // => Ok

Any Idea how to solve this problem? Thanks in advance for your suggestions...

• I am using the version of 31. March
• SelfServicing
• SQLServer
• All entities are identified by the field ID
• All entities have a field CustomerID.

Edit: By the way: Also FooCollection.GetMulti( null ) has to add the filter automatically.

Either you change all your entities PK's to be composed of ID & CustomerID.

Or the more generalized way is to have a global predicate that you should use to fetch Entities and EntityCollections.

PredicateExpression filterByCustomer = new PredicateExpression();
filterByCustomer.Add(CustomerFields.ID == Global.CustomerID);

Walaa wrote:

Either you change all your entities PK's to be composed of ID & CustomerID.

Or the more generalized way is to have a global predicate that you should use to fetch Entities and EntityCollections.

PredicateExpression filterByCustomer = new PredicateExpression();
filterByCustomer.Add(CustomerFields.ID == Global.CustomerID);

You mean, that this filter should be set each time, as the application gets an entity or an entity collection. I dont think that, it is pratical if the application is big and the database with abt 200 tables. It is also buggy and erroneous.

Is there an easy, central and 100%-safe solution for this problem? Because in the application the data will be read from the db, modified then written back into the db and they must always be correct.

The PK fetches like foo = new FooEntity( 1 ); // => Ok foo = new FooEntity( 2 ); // => Error (not found) can't be altered, as the filter produced for the entity is based on the PK field. Adding another filter is not what the framework should do, as it doesn't make sense for the framework.

There is a way to automate this, although I'm not sure if it will work in every part of the framework. - create an include template for the dao classes. In there override CreatePrimaryKeyFilter. There, add the CustomerID filter to that filter. Also override the CreatePrimaryKeyFilters variant, if you use hierarchies. If you override the latter, you don't need to override the first.

• for the getmulti actions, it's a different story, you'll have to use a central method for that I think, which produces the real filter to use. The issue is that there's no virtual method to override in the GetMulti-call chain so you can't append your extra filter to the filter to use. The lazy loading methods for collections will use the generated CreateFilterUsingForeignKeys.

So it's complicated. The problem is also with prefetch paths, which have to get the filter.

If anything fails, a small change to the DQE of sqlserver is an option. As there's just 1 select query construction method, you can simply add the filter there, based on a property set for example. The only thing to overcome then is to avoid having the filter also added to subqueries (however it might be that that IS wanted).

If you don't want to alter the sourcecode, you can derive a class from the DynamicQueryEngine and override the selectquery construction method. The DAO classes set the DQE to use in the constructor. You could create a derived class for the DAO classes, set the DQE in THAT one's constructor (using a template of course) and then you can let the code instantiate instances of the new DAO classes in the collection classes and entity classes by overriding CreateDAOInstance() in which you create your own DAO variant.

Thank you!

If anything fails, a small change to the DQE of sqlserver is an option. As there's just 1 select query construction method, you can simply add the filter there, based on a property set for example. The only thing to overcome then is to avoid having the filter also added to subqueries (however it might be that that IS wanted).

...was exactly what I was looking for!

PS: I hope you have something similar planned for v2.0? I think that is a common issue. Don't you agree?

Spaunk wrote:

Thank you!

If anything fails, a small change to the DQE of sqlserver is an option. As there's just 1 select query construction method, you can simply add the filter there, based on a property set for example. The only thing to overcome then is to avoid having the filter also added to subqueries (however it might be that that IS wanted).

...was exactly what I was looking for!

I'm glad it solves your problem

PS: I hope you have something similar planned for v2.0? I think that is a common issue. Don't you agree?

I'm not planning to add this kind of feature as it's very application specific.